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 <[email protected]>: > 2009/11/14 Adrian Lienhard <[email protected]>: >> 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 >>> > > 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 >>> [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 >> > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
