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