On 12 August 2011 12:12, Lukas Renggli <[email protected]> wrote:
> Yes, exactly.
>
> Ideally we should probably implement the number parsing in
> PetitParser. Maybe as a separate parser that can be used in
> PPSmalltalkGrammar? If you want to give it a try, I am happy to review
> it.

Yes, I'm happy to do that.

I assume (I'll check later too...) that Pharo has a test suite
describing number syntax? That'll give me something I can steal/copy
for the number subgrammar. While I try figure out if Squeak actually
meant to have Number readFrom: '1.' == 1.0, I'll work against Pharo's
idea of what a number is. I can see dialect-specific subclassing
parsers anyway, which can live in separate packages. (I've got a
largely-working Gnu Smalltalk parser working, for instance (modulo my
limited understanding of gst's grammar).)

frank

> Lukas
>
> On 12 August 2011 12:50, Frank Shearar <[email protected]> wrote:
>> On 11 August 2011 23:30, Lukas Renggli <[email protected]> wrote:
>>>
>>>
>>> On Friday, 12 August 2011, Frank Shearar <[email protected]> wrote:
>>>> On 11 August 2011 22:05, Lukas Renggli <[email protected]> wrote:
>>>>> Hi Frank,
>>>>>
>>>>>> I asked Lukas and he said that since others would be interested, I
>>>>>> should repost the question here. So:
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> Gnu Smalltalk's class variable declarations take the form of
>>>>>> [<identifier> := <expression>.]* at the end of an object definition.
>>>>>> To that end I wrote a #classVars production like so:
>>>>>>
>>>>>>   classVars
>>>>>>       ^ (assignment , expression , $. asParser) star
>>>>>>       "Possibly I need to support the lack of a dot on the last
>>>>>> expression. Not relevant at the moment"
>>>>>
>>>>> This seems to be indeed the same problem as the simpler case below ...
>>>>>
>>>>>> This didn't work as expected. Looking further, I found this oddity:
>>>>>>
>>>>>>   p := PPSmalltalkParser new.
>>>>>>   p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)"
>>>>>>
>>>>>> I would expect this to fail, because "1." isn't a number (but see
>>>>>> below).
>>>>>
>>>>> This fails in Pharo 1.3. In fact, in Pharo the following statements
>>>>> return 'false':
>>>>>
>>>>>  | s |
>>>>>  s := '1.' readStream.
>>>>>  Number readFrom: s.
>>>>>  s atEnd
>>>>>
>>>>> That is, #readFrom: really only consumes what it can. I don't know
>>>>> what Smalltalk you use, but I guess your image consumes the $. and
>>>>> returns 'true'. Not sure if this can be called a bug, but it is
>>>>> definitely a bit strange. The definition of a valid number literal is
>>>>> quite different among different Smalltalk dialects, thus I decided to
>>>>> rely on the built-in implementation of Number class>>#readFrom:.
>>>>
>>>> I'm using Squeak (trunk), and there we have
>>>>
>>>>    Number readFrom: '1.' readStream "=> 1.0"
>>>>    Number readFrom: '1' readStream "=> 1"
>>>>
>>>> So what might be happening is that the stream contains '1.' but
>>>> Pharo's version doesn't care, and returns an Integer?
>>>>
>>>> Ah. Ahem. Indeed, that's what's happening. Number gets '1.', and in
>>>> Pharo that means 1 while in Squeak it means 1.0.
>>>>
>>>> I find it a bit strange that PPSmalltalkGrammar sends off '1.', but I
>>>> also think that Squeak's doing the wrong thing.
>>>
>>> PPSmalltalkGrammar doesn't send off anything, it just delegates to the
>>> number reader by passing over its stream. In return PPSmalltalkGrammar
>>> expects a number and that the number reader leaves the stream at the end of
>>> the number. This is the same than the refactoring browser parser and the
>>> standard compiler do in Pharo (I believe).
>>
>> OK. So when parsing '1.' readStream. PPSmalltalkGrammar will send off
>> (a stream containing) '1.' to something (in this case Number class >>
>> #readFrom:), which will eat the Number. Then PPSmalltalkGrammar picks
>> up the stream with whatever's still left unparsed.
>>
>> In Pharo's case that means that 1 is returned, leaving '.' on the
>> stream; in Squeak's case Number eats the '1.', returns 1.0 and then
>> leaves the stream empty.
>>
>> Is that an accurate restatement of the issue?
>>
>> frank
>>
>>> Lukas
>>>
>>> --
>>> Lukas Renggli
>>> www.lukas-renggli.ch
>>>
>>
>>
>
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
>

Reply via email to