Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.7-25-g990b11c

[Ludovic Courtès]

Hi!

Andy Wingo <address@hidden> skribis:

> On Fri 11 Jan 2013 18:15, address@hidden (Ludovic Courtès) writes:
>
>> "Andy Wingo" <address@hidden> skribis:
>>
>>> address@hidden string->bytevector string encoding 
>>> [#:conversion-strategy='error]
>>
>> An optional instead of keyword argument would look nicer, IMO.
>
> Nicer in the docs or nicer to use?

Both, IMO.

> Just as a meta-level thing, I think we should prefer keywords over
> optional arguments unless we can convince ourselves that there won't be
> any other options.  If you end up having two independent optional
> arguments, you'd have been better off going with keywords from the
> beginning.

Agreed.

> In this case probably there won't be another optional argument, but I
> couldn't mentally rule it out, so I went with the keyword.  Anyway,
> doesn't matter much :)

That was my reasoning: there won’t be any other option here.

>>> +Encode @var{string} as a sequence of bytes.
>>> +
>>> +The string will be encoded in the character set specified by the
>>> address@hidden string.  If the string has characters that cannot be
>>> +represented in the encoding, by default this procedure raises an
>>> address@hidden,
>>
>> I think this doesn’t leave a way to know which character in STRING could
>> not be converted.  It would be ideal if that information could be
>> provided as part of the exception, as is the case with ports (tested
>> with ‘test-decoding-error’ in ports.test.)
>
> You sure?  It's implemented using ports in the general case.  And what
> about the case for bytevector->string?

Likewise.  When using iconv(3) in C, it’s possible to know at which
position the input failed to be converted.

>> Not a single docstring.  Now I feel ashamed when asking Nala to add
>> docstrings.  ;-)
>
> There are only three functions!  You make it sound like I'm in the back
> room strangling kittens :P  Anyway, fixed.

You make it sound like I’m the Brigitte Bardot of docstrings!  :-)

> Incidentally, it would be nice to start using texinfo in docstrings, and
> use (texinfo serialize) to render them.

That’d be ideal, but I wonder whether there are tools around that would
end up displaying raw Texinfo, such as anything that use
‘procedure-documentation’.  Perhaps that can be solved easily.

Thanks,
Ludo’.