2015-09-25 11:01 GMT+02:00 Nicolai Hess <[email protected]>: > > > 2015-09-24 22:39 GMT+02:00 Thierry Goubier <[email protected]>: > >> Le 24/09/2015 09:11, Nicolai Hess a écrit : >> >>> >>> >>> 2015-09-24 8:19 GMT+02:00 Peter Uhnák <[email protected] >>> <mailto:[email protected]>>: >>> >>> > - 250 * 1.5 returns -2.25 >>> >>> why is this valid syntax? >>> >>> >>> >>> I don't know if this is valid syntax (I always wondered that there is >>> one place in PointTest, that is not compilable with old compiler but >>> compiles >>> fine with opal). >>> But the error happens in >>> RBParser>>#parseNegatedNumber. >>> If a #- is recognized, it tests if a literalnumber follows (but from the >>> token stream, that is, the spaces are ignored). >>> Now the real bug is, that we do two "steps" and concstruct a new >>> literalvaluenode from the now following tokens. >>> RBParser parseExpression:'- 2' -> throws an error, because no following >>> tokens >>> RBParser parseExpression:'- 2 * 3' -> works but actually duplicates the >>> two last tokens "*3 *3. >>> and some funny other things '- 2@1' -> '-1@1' >>> >> >> Another one I found in the tests: would you expect >> >> RBParser parseExpression: '# >> >> 1 = 1' >> >> To be the same thing as '#1 = 1' ? >> > > > And another one: > #t = ##t "-> true" > > I thnk ##t should be allowed. >
I would allow it if it doesn't impact the code. At the moment, what I see is that ## is allowed because #scanLiteral is recursive for symbols... sort of side effect of the current implementation. If correcting makes it non-recursive, I won't introduce a special check to allow ## and ### and ####. ## has a special meaning in some smalltalks (Dolphin?). Removing ## would make porting Dolphin code (SmaCC, for example) harder. Thierry > > > >> >> Thierry >> > >
