Status about compiler _ changes

> As far as I remember from the other mail-thread there was consensus to
> allow underscores in identifiers and get rid of underscores in
> assignments. What is unclear for me is how we want to proceed and when
> to integrate it?
>
> 1. Do we just change the scanner for 1.1 without fallback?
>
> 2. Do we add a setting (fix the existing setting) so that the scanner
> can be changed on demand?
>
> I prefer 1, because it is simpler and does not allow the system to be
> in an inconsistent state. 2 is more convenient for people, because
> they can change the setting to load old code, fix the code and change
> the setting back. Potentially that leaves the system in an
> inconsistent state though.

> As far as I remember from the other mail-thread there was consensus to
> allow underscores in identifiers and get rid of underscores in
> assignments. What is unclear for me is how we want to proceed and when
> to integrate it?
>
> 1. Do we just change the scanner for 1.1 without fallback?
>
> 2. Do we add a setting (fix the existing setting) so that the scanner
> can be changed on demand?
>
> I prefer 1, because it is simpler and does not allow the system to be
> in an inconsistent state. 2 is more convenient for people, because
> they can change the setting to load old code, fix the code and change
> the setting back. Potentially that leaves the system in an
> inconsistent state though.

>> Now could not we have 3?
>>         3
>>         do 1 (ie no preference) but transform the code from _ into := automatically.
>> It would be really great in fact
>
> That would be the magic solution :-)
>
> The problem is that it would not be clear how to parse a_1. Is it the
> assignment of 1 to a or the access of the variable a_1?
>
> I don't like the proposal of requiring a delimiter before and after an
> underscore assignment: (1) there is existing code where this is not
> the case, (2) it complicates the scanning significantly, the same
> token represents different things depending on context and an extended
> lookahead is required to parse it, and (3) it allows that people
> continue to use crappy underscore assignments, there will be a mess
> forever.
>
> Lukas
>

> As far as I remember from the other mail-thread there was consensus to
> allow underscores in identifiers and get rid of underscores in
> assignments. What is unclear for me is how we want to proceed and when
> to integrate it?
>
> 1. Do we just change the scanner for 1.1 without fallback?
>
> 2. Do we add a setting (fix the existing setting) so that the scanner
> can be changed on demand?
>
> I prefer 1, because it is simpler and does not allow the system to be
> in an inconsistent state. 2 is more convenient for people, because
> they can change the setting to load old code, fix the code and change
> the setting back. Potentially that leaves the system in an
> inconsistent state though.
>
> Lukas

>> Now could not we have 3?
>>         3
>>         do 1 (ie no preference) but transform the code from _ into := automatically.
>> It would be really great in fact
>
> That would be the magic solution :-)
>
> The problem is that it would not be clear how to parse a_1. Is it the
> assignment of 1 to a or the access of the variable a_1?
>
> I don't like the proposal of requiring a delimiter before and after an
> underscore assignment: (1) there is existing code where this is not
> the case,

>> Now could not we have 3?
>>        3
>>        do 1 (ie no preference) but transform the code from _ into := automatically.
>> It would be really great in fact
>
> That would be the magic solution :-)
>
> The problem is that it would not be clear how to parse a_1. Is it the
> assignment of 1 to a or the access of the variable a_1?
>
> I don't like the proposal of requiring a delimiter before and after an
> underscore assignment: (1) there is existing code where this is not
> the case, (2) it complicates the scanning significantly, the same
> token represents different things depending on context and an extended
> lookahead is required to parse it, and (3) it allows that people
> continue to use crappy underscore assignments, there will be a mess
> forever.
>
> 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

> 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

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

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