Re: [PATCH v1 02/36] Guile extension language: doc additions

[ludo at gnu dot org (Ludovic CourtÃs)]

Eli Zaretskii <eliz@gnu.org> skribis:

>> >> +@defun value? object
>> 
>> What about distinguishing Scheme functions, like:
>> 
>>   @deffn {Scheme Procedure} value? object
>
> If it's important (is it?), then yes.

I think I would find it clearer, to someone who skims over the manual.

>> >> +If @var{type} is not provided,
>> >> +a Scheme real is converted to the C @code{double} type for the
>> >> +current architecture.
>> >
>> > Isn't Guile built with libgmp?  If so, doesn't it support floats
>> > which, when converted to a double, will lose accuracy?
>> 
>> Guile uses GMP, but GMP is for integers (bignums).
>
> What about long double support?

Guile doesnât support it out of the box.

If needed, it could easily be implemented as an extension: one would use
a SMOB to wrap long doubles and pass them to Scheme, and possibly define
methods for â+â, â-â, etc. for objects of this type.

Of course, this wouldnât be terribly efficient, but thatâs not so
important here I think; what matters is that it would allow âlong
doubleâ values to be passed around without loss of accuracy.

That said, my feeling is that leaving things as is (with long doubles
cast to doubles) may prove to be sufficient for most practical uses of
GDB.

WDYT?

>> >> +A Scheme string is converted to a target string, using the current
>> >> +target encoding.
>> >
>> > What if target encoding doesn't support some of the characters in the
>> > string?
>> 
>> Guileâs behavior can be controlled with
>> â%default-port-conversion-strategyâ: it can raise an exception, or
>> substitute any characters that could not be converted, or escape them
>> (info "(guile) Ports").
>> 
>> Perhaps this should be briefly mentioned, with a cross-ref.
>
> It should, because the issue will certainly arise, especially since
> (AFAIU) Guile prefers UTF-8.

Right.  (UTF-8 is just the default encoding for source code; itâs not
âpreferredâ in any other way.)

>> >> +If the optional @var{length} argument is given, the string will be
>> >> +fetched and encoded to the length of characters specified.  If
>> >> +the @var{length} argument is not provided, the string will be fetched
>> >> +and encoded until a null of appropriate width is found.
>> >
>> > Isn't this null termination description skewed towards C-like
>> > languages?  Aren't there languages where strings don't have to be
>> > null-terminated?
>> 
>> Yes, and thatâs when LENGTH should be provided, AIUI.
>
> Then I guess the above should say that explicitly.  But it would be
> nice if GDB could support strings in languages that don't
> null-terminate even without LENGTH.

Agreed (I had misread the description above as saying that, if LENGTH is
provided, then the string is *not* assumed to be nul-terminated.)

Thanks,
Ludoâ.