Re: Inconsistency in `string-to-number'

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Actually it could also break code (tho it seems unlikely).  I wouldn't
>> mind postponing the fix to Emacs-23.2.  In the mean time, we need to
>> improve the docstring.
> The docstring was not improved, and we're now on the 23.2 track, so
> time for a reprieve.

Sorry, your email got misfiled.

> Reminder: The problem is the following inconsistency:

>   (string-to-number "1:")  =>  1
>   (string-to-number "1.2:")  =>  1
>   (string-to-number "1.2") =>  1.2

> Alas, the docstring talks about "leading spaces and tabs", but says
> nothing about trailing chars.

> Currently the behavior, depending of the first non-digit after the
> number, is as follows:

>  - \0, \s, \r, \n, \f and \t  => the number is read as a float (if
> base == 10) or integer, as intended.
>  - Any other char: the number is always interpreted as an integer.

> Possibilities:

>  0) Do nothing except clarifying the docs.
>      Pro: easier of all fixes.
>      Cons: inconsistency.

That would be documenting a bad behavior, so that would only be
acceptable if the new doc says "if there's something after the number,
you're on your own".

>  1) Disallow any trailing char.
>      Pro: follows the doc (sort of).
>      Cons: incompatibility with current uses of undocumented "1:", etc.

That's not a good option, no.  I know there is code out there in use
that relies on this behavior (I'm probably guilty myself), but I don't
know how to find it to fix it, so I'd rather stay away from this.

>  2) Allow only whitespace: the same chars that the float case admits right now.
>      Pro: quite intuitive (IMO), easy to implement.
>      Cons: Same as 1)

Indeed, same as above.

>  3) Allow any trailing char.
>      Pro: forgiving.
>      Cons: (unlikely) incompatibility with uses of undocumented "1.2:" => 1

That would be my choice.  The behavior is still fairly regular, so the
doc shouldn't be too scary, and it works about as well as now.

> I like 2), because it seems cleaner to just allow whitespace all
> around the number; it has a certain risk of incompatibility, though.
> 1) and 3) would require adding a new parameter to
> lread.c:isfloat_string() or somesuch; not hard, but not very clean.

I'd need to see the patch to pronouce myself on the uncleanliness.


        Stefan