Lex Spoon a écrit :
nicolas cellier ncellier@ifrance.com writes:
As stated in NewCompiler's code, the ANSI syntax:
These are fun challenges, Nicolas! They will help us get a compiler that does precisely what we want from it.
In deciding the behavior we want, I would propose two principles, the first being stronger than the last:
- Be compatible on the trivial stuff. Save Squeak-isms for places
where there is a real advantage.
- Lean towards accepting more rather than less. Especially we
should try to accept things that other implementations accept.
Very reasonnable. But which dialect does interpret '- 1' the ANSI way? Not VW, nor gst, nor stx... (didn't check Dolphin nor VA)
Here are my attempts to figure out what ANSI actually wants in these cases. Be aware it is not always what the compiler is currently doing.
ClosureCompiler evaluate: '- 1'
is WEIRD! It answers -1 as a literal negative number, space not being significant. BEWARE a tab or cr are significant in current implementation (ANSI?)
This is more confusing than usefull. It makes people think of a prefixed operator like other languages.
The standard is clear. A unary - is allowed to dangle way ahead of the the number literal that it modifies.
Section 3.4.6.1 includes the appropriate rule. Note the last sentence.
<number literal> ::= ['-'] <number> <number> ::= integer | float | scaledDecimal If the preceding '-' is not present the value of the numeric object is a positive number. If the '-' is present the value of the numeric object is the negative number that is the negation of the positive number defined by the <number> clause. White space is allowed between the '-' and the <number>.As best as I can tell, the standard is factored this way so that you can divide your parser in the standard way into a tokenizer and a parser. When the tokenizer sees "-1", it should divide it into two tokens, "-" and "1". Then, the parser is free to interpreter this as either a literal, as in "x := -1", or a subtraction of 1, as in "y := x-1".
Since it's handled at the level of parsing, white space is allowed for consistency. You can even put comments in there if you like.
That's my rationalization, anyway. :) The rationale doesn't say, but the spec is clear that spaces are allowed there.
This makes some sense. Though not implemented that way in new compiler (only character spaces are allowed, not logical spaces).
This is more the gramar rule which is questionable. It's not based on any dialect customs, nor historical roots. Maybe the fact that people coming from other language may appreciate...
Also, as already said, inside literal array #(- 1) space is significant.
In this case, it should probably be the same as #(-1). The standard is generally too quiet about array literals, but in this case it does define a parse, so I guess we should use the standard parse.
If you want to parse a two-element array out of the above, you can write it as: #(#- 1) .
I would not like it. I prefer to understand the rule as: 1) a space separates two tokens 2) -1 is a single token not two, while - 1 is two tokens 3) a literal array is an array of literal tokens
My guess is that this was the rule in the mind of Smalltalk gods. Only a guess...
Anyway, it's the actual behaviour of most Smalltalks.
And what about the sign of exponent? ClosureCompiler evaluate: '-1.0e- 1'. Message not understood e ((-1.0) e) - (1), so space is significant here.
According to the standard, the only place you can insert a space inside a number literal is if the whole literal starts with a "-". This (ugly) exception only applies at the beginning, and not in the example you give.
Not a brilliant example anyway, forget it.
Beside, as NewCompiler accepts minus as last character of a multi-character binary selector, this causes further ambiguity.
ClosureCompiler evaluate: '0--1'. is 1 (0-(-1)) last minus is attached to digit because there is no space.
This code is incorrect by the standard, and I'd be happy with rejecting it. ANSI uses normal old longest match. Section 3.5 says:
Unless otherwise specified, white space or another separator must appear between any two tokens if the initial characters of the second token would be a valid extension of the first token.Thus, 0--1 should tokenize as "0", "--", "1", which then does not parse.
Lex Spoon
Yes, just like #||, #-- is not standard. It is an extension. For the very reason to avoid ambiguity caused when mixed with negative literal numbers if i understood it well.
It would be easy to have a pedantic interactive compiler forcing user to disambiguate (at least warning, or a menu proposing various interpretations with auto-inserting space action).
See: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/thread.html#... http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/104088.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103907.html etc... (binary selectors ambiguity and space)