[squeak-dev] Bug in Number parsing?
frank.shearar at gmail.com
Fri Aug 12 10:50:04 UTC 2011
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:
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.
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:
> 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).
>> 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:
>>> Though, in Smalltalk source code, the SqNumberParser is used and you can't.
>>> 2011/8/12 Frank Shearar <frank.shearar at gmail.com>:
>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>> 1.0 ... I'd expected a 1.
>>>> Is this expected behaviour?
More information about the Squeak-dev