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

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