Bug in Number parsing?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in Number parsing?

Frank Shearar-3
Hi,

While playing around, I've found that Number readFrom: '1.' returns
1.0 ... I'd expected a 1.

Is this expected behaviour?

frank

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Nicolas Cellier
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 <[hidden email]>:

> Hi,
>
> While playing around, I've found that Number readFrom: '1.' returns
> 1.0 ... I'd expected a 1.
>
> Is this expected behaviour?
>
> frank
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Nicolas Cellier
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 <[hidden email]>:

> 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 <[hidden email]>:
>> Hi,
>>
>> While playing around, I've found that Number readFrom: '1.' returns
>> 1.0 ... I'd expected a 1.
>>
>> Is this expected behaviour?
>>
>> frank
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Nicolas Cellier
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 <[hidden email]>:

> 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>> Hi,
>>>
>>> While playing around, I've found that Number readFrom: '1.' returns
>>> 1.0 ... I'd expected a 1.
>>>
>>> Is this expected behaviour?
>>>
>>> frank
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Frank Shearar-3
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
<[hidden email]> 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 <[hidden email]>:
>> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>> Hi,
>>>>
>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>> 1.0 ... I'd expected a 1.
>>>>
>>>> Is this expected behaviour?
>>>>
>>>> frank
>>>>
>>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Nicolas Cellier
2011/8/12 Frank Shearar <[hidden email]>:

> 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
> <[hidden email]> 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 <[hidden email]>:
>>> 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 <[hidden email]>:
>>>> 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 <[hidden email]>:
>>>>> Hi,
>>>>>
>>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>>> 1.0 ... I'd expected a 1.
>>>>>
>>>>> Is this expected behaviour?
>>>>>
>>>>> frank
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Frank Shearar-3
On 12 August 2011 14:35, Nicolas Cellier
<[hidden email]> wrote:

> 2011/8/12 Frank Shearar <[hidden email]>:
>> 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.

Fair enough:

    a := 1..
    a "=> 1, so '..' means 'end statement, end (empty) statement'."


But that means that we have a number parser that permits a grammar
that doesn't match the host language's grammar, right? To be precise,
SqNumberParser says "SqNumberParser is a NumberParser specialized in
reading Number with Squeak syntax." but actually accepts something
slightly different from Squeak syntax.

Again: if there's good reason for this, that's fine - that would just
mean I've been surprised. It just seems... odd.

For my personal needs, the right thing's probably to extend
PetitSmalltalk to parse numbers, instead of "calling out" to Number
class >> readFrom: to parse the numbers.

> Nicolas
>
>> On 12 August 2011 09:26, Nicolas Cellier
>> <[hidden email]> 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 <[hidden email]>:
>>>> 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 <[hidden email]>:
>>>>> 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 <[hidden email]>:
>>>>>> Hi,
>>>>>>
>>>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>>>> 1.0 ... I'd expected a 1.
>>>>>>
>>>>>> Is this expected behaviour?
>>>>>>
>>>>>> frank
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Bug in Number parsing?

Nicolas Cellier
2011/8/12 Frank Shearar <[hidden email]>:

> On 12 August 2011 14:35, Nicolas Cellier
> <[hidden email]> wrote:
>> 2011/8/12 Frank Shearar <[hidden email]>:
>>> 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.
>
> Fair enough:
>
>    a := 1..
>    a "=> 1, so '..' means 'end statement, end (empty) statement'."
>
>
> But that means that we have a number parser that permits a grammar
> that doesn't match the host language's grammar, right? To be precise,
> SqNumberParser says "SqNumberParser is a NumberParser specialized in
> reading Number with Squeak syntax." but actually accepts something
> slightly different from Squeak syntax.
>

Not exactly, apart NaN/Infinity, SqNumberParser adheres to
SqueakSyntax, but it is another class ExtendedNumberParser which is
used in Number readFrom:.

> Again: if there's good reason for this, that's fine - that would just
> mean I've been surprised. It just seems... odd.
>

I would see this in the perspective of Date readFrom:, which accepts
some formats which are not literal Smalltalk expressions, but rather
DSL.

> For my personal needs, the right thing's probably to extend
> PetitSmalltalk to parse numbers, instead of "calling out" to Number
> class >> readFrom: to parse the numbers.
>

Sure, this sounds wiser, but you'll have a Squeak/Pharo specific flavour.
I understand that Lukas was using Number readFrom: to handle
differences between Smalltalk dialects:
- VW 1.0e 1.0d 1.0s
- Dolphin 1.0e+0
- Squeak  2r1.01e-3 (broken in Squeak 4.1 or 4.2 for base > 14 since
we now accept lower case digits, and we can't distinguish e the digit
and e the exponent)
Anyway, there are other differences, like number of characters and
allowed characters in binary selectors, #[], {}, ##() , #{},
international characters in messages/variable names, etc...
so having a dialect specific parser does not hurt...

Nicolas

>> Nicolas
>>
>>> On 12 August 2011 09:26, Nicolas Cellier
>>> <[hidden email]> 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 <[hidden email]>:
>>>>> 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 <[hidden email]>:
>>>>>> 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 <[hidden email]>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> While playing around, I've found that Number readFrom: '1.' returns
>>>>>>> 1.0 ... I'd expected a 1.
>>>>>>>
>>>>>>> Is this expected behaviour?
>>>>>>>
>>>>>>> frank
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>