>> (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
