[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inconsistency in `string-to-number'
From: |
Stefan Monnier |
Subject: |
Re: Inconsistency in `string-to-number' |
Date: |
Tue, 01 Dec 2009 15:15:59 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
>> 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
- Re: Inconsistency in `string-to-number',
Stefan Monnier <=