Again, while we're at it… The definition of PPSmalltalkGrammar>>#binary looks wrong. It would not parse -- (double dash) as a binary selector. Camillo and I added a few tests for this, and a quick fix, but the way that rule was written suggests it was voluntary to forbid dashes after the first character.
I guess it should be scrutinized a bit more, especially since I think various dialects accept different lengths and characters for binary selectors… On 12 August 2011 00: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). > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
