2011/8/12 Frank Shearar <frank.shearar at gmail.com>:
> On 12 August 2011 14:35, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 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.
>
> 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
>>> <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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>