On Nov 14, 2009, at 4:38 PM, 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.
yes :) This is why discussion is good since common knowledge emerges. > 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: [email protected] > [mailto:[email protected]] On Behalf Of Lukas > Renggli > Sent: Saturday, November 14, 2009 4:01 AM > To: [email protected] > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
