Hi!
Andy Wingo <wi...@pobox.com> skribis:
> On Fri 11 Jan 2013 18:15, l...@gnu.org (Ludovic Courtès) writes:
>
>> "Andy Wingo" <wi...@pobox.com> skribis:
>>
>>> +@deffn 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
>>> +@var{encoding} string. If the string has characters that cannot be
>>> +represented in the encoding, by default this procedure raises an
>>> +@code{encoding-error},
>>
>> 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’.
