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
