> 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:
[hidden email] [mailto:
[hidden email]] On Behalf Of Lukas Renggli
> Sent: Saturday, November 14, 2009 4:01 AM
> To:
[hidden email]
> 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
>
[hidden email]
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project>
> _______________________________________________
> Pharo-project mailing list
>
[hidden email]
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
