Hi Damien,
I knew there was something strange sometime with number parsing: do you
remember the thread "[BUG] nil ~= 1and: [1 isNil] is parsed+compiled
without complaint".
That time it was decided, IIRC, that '1and' parses '1' then 'and'
correctly.
So what can a sender of #readFrom: do
- a) decide that it will indeed send #readFrom: and
- b) decide what to do if no digit is before the first nonDigit, nonMinus
character.
One solution would be that (Number>>readFrom: 'and') returned nil, just to
make it different from (Number>>readFrom: '0and').
OTOH the Scanner handles the case when Number>>readFrom: signals an error,
why doesn't everybode else do so ;-)
/Klaus
On Wed, 21 Mar 2007 15:06:04 +0100, Damien Cassou wrote:
> Nicolas told me that this bugs follows the bug:
>
http://bugs.impara.de/squeak/view.php?id=3512>
>
> The aim of the test is to verify that an error is thrown instead of 0
> which is a number and should not indicate an error. The only place
> where we will get an error is if the stream starts by $r which is
> stupid.
>
> Number readFrom: 'a' => 0
> Number readFrom: 'r' => ERROR
>
> Nicolas proposes to replace Number>>readFrom: to use his parser (which
> is already in the image but not used by default: SqNumberParser). The
> only problem with its parser is the non backward compatible behavior
> on that problem.
>
> So, what do we do?
>
Locked
