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