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