[Top][All Lists]

[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)


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.


> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]