Folks, I suggest we follow solution 1 in order to not be stuck. Then we will add backward compatibility hacks if necessary and if not too much ugly. Agree ? Nicolas 2009/11/14 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/11/14 Adrian Lienhard <adi@netstyle.ch>:
OK, then, we do Lukas' option 1: "change the scanner for 1.1 without fallback".
Adrian
On Nov 14, 2009, at 16:38 , Schwab,Wilhelm K wrote:
I feel somewhat responsible for this branch of the thread :( Â For the record, I am freely willing to "give up" underscore assignment. The idea of allowing it via a whitespace trick seemed worthy of due consideration, but I am liking it less as the debate continues.
IIRC, the whole mess got started over a desire to have a single keypress for assignment.  Sadly, I was not consulted, because that could have been accomplished as an optional feature of the editor (_ inserts :=, backing up over = removes a preceding :, turn it off if you want  no part of it; done), but it was instead allowed to seep into the compiler and the sources.
It can't go away too soon for my tastes, but a transition period makes sense too. Â Whatever you guys want to do is fine by me. Thanks for tackling the problem!!
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes
(2) it complicates the scanning significantly, the same token represents different things depending on context and an extended lookahead is required to parse it,
I'm afraid I'm not seeing this point. From a brief look at the scanner, it appears that allowing := assignment did complicate the scanner somewhat, but that allowing _ to mean assignment should be similar complexity and still only require one-char lookahead. But perhaps I'm missing something.
You need to make sure that there is a delimiter (or comment) before and after the underscore character, which I think is not trivial to scan. Certainly possible, but not trivial.
Furthermore it would make it impossible to write code like
  a _ b
where a is a variable, #_ and #b are unary messages. The above code is valid in other Smalltalk dialects.
and (3) it allows that people continue to use crappy underscore assignments, there will be a mess forever.
I can't (and don't want to) argue with that :-) I'll gladly accept "we don't want to allow underscore assignment" as an argument, I'm not so sure about the "it's hard" argument.
I am not saying it is impossible.
My main concerns are the following:
1. I don't like that _ means different things depending on context. 2. I don't like that the use of _ in identifiers has unnecessary restrictions and exceptions. 3. I don't want to break compatibility with other Smalltalk dialects. 4. I don't want to see _ as assignment operator anymore. 5. I don't want to rewrite the complete compiler, there are probably more changes coming from Eliot for closures, the stack VM and the JIT. I don't want to make integrating those unnecessarily hard. 6. I don't want to break irreparably other tools that depend on the Smalltalk syntax like the Refactoring Engine or the NewCompiler.
Lukas
I'm quite sure we can handle this via notifications or errors and appropriate handlers with very few hacks in Compiler/Parser. This would occur only in batch mode.
For example: - emit a warning when #'_' message is sent - handle in batch-mode handler by setting a flag (doesUseUnderscoreAsAMessage) and let the code proceed - let handler restart compilation with a modified typeTable if another Error/Warning is issued
Nicolas.
Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project