2011/8/12 Frank Shearar <frank.shearar at gmail.com>:
> I went and looked (rather belatedly, in hindsight) at the tests, and
> indeed we explicitly support (as in there are tests documenting the
> behaviour) the parsing of '1.' as a string representation of 1.0.
>
> My immediate issue is that this makes my work on Coral more
> complicated, because in Pharo Number readFrom: '1.' returns 1 and
> leaves '.' on the stream (just like it would for Number readFrom:
> '1x').
>
> But it also means we have an ambiguity in our grammar: there's no way
> to know whether in '1.' the dot belongs to the number literal, or
> whether it terminates the statement.
>
> frank
>

Well, no, because we do not use Number class>>readFrom: in the Parser.

Nicolas

> On 12 August 2011 09:26, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> For the sake of it, I would say things are not worse than before I put
>> my big nose in the code:
>>
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.html
>>
>> Nicolas
>>
>> 2011/8/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> This was changed in:
>>>
>>> The Trunk: Compiler-nice.125.mcz
>>> The Trunk: Kernel-nice.404.mcz
>>>
>>> The rationale is that (Number readFrom: ) is a very poor way to report
>>> a syntax error in the number.
>>> SqNumberParser can do much better when invoked with ad hoc API.
>>>
>>> This release the necessity for Number>>readFrom: to strictly adhere to
>>> Smalltalk syntax (which it did not since it also interprets infinity
>>> and nan).
>>>
>>> Nicolas
>>>
>>> 2011/8/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>>> Yes, in Squeak this behavior is obtained with the ExtendedNumberParser.
>>>> You can read these floats for example:
>>>>
>>>> 1.
>>>> 1.e+30
>>>> .1
>>>> -.1e+30
>>>>
>>>> Though, in Smalltalk source code, the SqNumberParser is used and you can't.
>>>>
>>>> Nicolas
>>>>
>>>> 2011/8/12 Frank Shearar <frank.shearar at gmail.com>:
>>>>> Hi,
>>>>>
>>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>>> 1.0 ... I'd expected a 1.
>>>>>
>>>>> Is this expected behaviour?
>>>>>
>>>>> frank
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>