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 -- 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