Le 25/09/2015 19:35, stepharo a écrit :
I would keep ## if in the future we need a new syntactic sugaring construct.
Why keep it if it is easy to add once you know you need it? For now,
this code allows things like:
RBParser parseExpression: '#####################################t'
Note on all those funny symbol syntaxes: formatting will get rid of them.
Another fun syntax example:
RBParser parseExpression: '#"
I
am
a
quite
long
comment"
t'
Thierry
Le 25/9/15 09:01, Nicolai Hess a écrit :
2015-09-24 22:39 GMT+02:00 Thierry Goubier <[email protected]
<mailto:[email protected]>>:
Le 24/09/2015 09:11, Nicolai Hess a écrit :
2015-09-24 8:19 GMT+02:00 Peter Uhnák
<<mailto:[email protected]>[email protected]
<mailto:[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.
Thierry
