[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.7-25-g99
From: |
Ludovic Courtès |
Subject: |
Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.7-25-g990b11c |
Date: |
Sat, 12 Jan 2013 00:39:39 +0100 |
User-agent: |
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) |
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’.