[Pharo-project] 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. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Fri, Nov 13, 2009 at 1:16 PM, Lukas Renggli <renggli@gmail.com> wrote:
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.
I vote 1. However, if we could provide a simple script that runs on version 1.0 and that fixes the code or at least point to _ uses, that would be cool. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry
On Nov 13, 2009, at 1:16 PM, Lukas Renggli wrote:
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.
2 would be nice because as integrators we could make sure that the code is in consistent state even with pain. 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 Stef
Stef, I have been making a lot of use of SIF. There are some silly problems with method categories that I have learned to remember (the hard part<g>) to fix using even search and replace, but I have also done some "refactoring" using the regex package and match/replace. Assuming you have an image with offending code, an expression that matches an isolated $_ (white space on either side) migh be able to fix assignments by replacing the matches with :=. It might be useful on its own, and it brings up another proposed solution, which is to optionally treat isolated underscores as assignments, and to treat them as part of identifiers when not bracketed on both sides by whitespace (from Gemstone??). Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Friday, November 13, 2009 8:12 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes On Nov 13, 2009, at 1:16 PM, Lukas Renggli wrote:
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.
2 would be nice because as integrators we could make sure that the code is in consistent state even with pain. 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 Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
2009/11/13 Lukas Renggli <renggli@gmail.com>:
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
It should be possible to forbid _ assignment in interactive mode, but still authorize in batch mode (loading an external package for example) to make sure those assignments disappear...
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It should be possible to forbid _ assignment in interactive mode, but still authorize in batch mode (loading an external package for example) to make sure those assignments disappear...
Yes, but you still wouldn't know if a_1 is an old assignment or a new variable access. Or am I missing something? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Em 13/11/2009 13:36, Lukas Renggli < renggli@gmail.com > escreveu:
It should be possible to forbid _ assignment in interactive mode, but still authorize in batch mode (loading an external package for example) to make sure those assignments disappear...
Yes, but you still wouldn't know if a_1 is an old assignment or a new variable access. Or am I missing something?
Lukas, I'm thinking aloud, so bear with me! I think that an "a_1." would be sintatically incorrect except if you can find a variable elsewhere a_1, right? My 0.0199999... -- Cesar Rabak
I'm thinking aloud, so bear with me! Â I think that an "a_1." would be sintatically incorrect except if you can find a variable elsewhere a_1, right?
The problem is that during the lexical analysis variable information is not yet available. Parsing a_1 different depending on the context would be extremely dangerous (the exact same code could mean two entirely different things depending on where you type it) and in many case not be possible (the refactoring engine needs to be able to parse code without knowing the context). Lukas -- Lukas Renggli http://www.lukas-renggli.ch
argh! I loved magic. In that case I would go for 2 because supporting migration is important. Stef
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Lukas Renggli wrote:
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,
A small minority of code, surely?
(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.
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. Regards, -Martin
(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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Nov 14, 2009, at 4:38 PM, 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.
No, the _ used to be rendered as a left-arrow. This comes from a time far, far away when there where less standards...build-your-own keyboad times. It was a left-over from Smalltalk 72 which had lots of graphical characters as part of the language. The _ was removed from all Smalltalks, just not from Squeak. This was because it felt to certain people that going ascii was a mistake anyway and that more graphical stuff should come again, not less. And removing the left-arrow betrays that vision. The fun thing is: I am all for experiments to go beyond text. But than it should be *real*. Just keeping the _ as a kind of "look, we are special" is idiotic. So we removed the funny character left-arrow and let it render what the _ (so people can deal with external code, c, or database rows...). Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Marcus, The left arrow is part of it, but single-key assignment was the big reason given to not fix it. The important thing is that Pharo is going to get it right. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Saturday, November 14, 2009 10:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes On Nov 14, 2009, at 4:38 PM, 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.
No, the _ used to be rendered as a left-arrow. This comes from a time far, far away when there where less standards...build-your-own keyboad times. It was a left-over from Smalltalk 72 which had lots of graphical characters as part of the language. The _ was removed from all Smalltalks, just not from Squeak. This was because it felt to certain people that going ascii was a mistake anyway and that more graphical stuff should come again, not less. And removing the left-arrow betrays that vision. The fun thing is: I am all for experiments to go beyond text. But than it should be *real*. Just keeping the _ as a kind of "look, we are special" is idiotic. So we removed the funny character left-arrow and let it render what the _ (so people can deal with external code, c, or database rows...). Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Marcus Denker wrote:
No, the _ used to be rendered as a left-arrow. This comes from a time far, far away when there where less standards...build-your-own keyboad times. It was a left-over from Smalltalk 72 which had lots of graphical characters as part of the language.
Smalltalk-80 used a blend of ASCII-1963 and ASCII-1967. In ASCII-1963, character code 16r5E was actually an up-arrow, and 16r5F was actually a left arrow. In ASCII-1967 those codes are caret and underscore. Regards, -Martin
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/14 Adrian Lienhard <adi@netstyle.ch>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <nicolas.cellier.aka.nice@gmail.com>:
2009/11/14 Adrian Lienhard <adi@netstyle.ch>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Nov 14, 2009, at 4:38 PM, 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.
yes :) This is why discussion is good since common knowledge emerges.
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El vie, 13-11-2009 a las 13:16 +0100, Lukas Renggli escribió:
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
I also vote for 1, but to manage the second case, the use is suggested to use a 1.0 image to change all the _ assignments and then export the package and load to the 1.1 image. As the 1.1 isn't the stable one, and the 1.0 will be the stable one, they will have time to change it. Besides. It isn't so big change to do either. Isn't as hard as rearchitecting the whole software or changing the inner implementation. It is a simple find and replace. And they have the slime rules to help. So go for the clean solution and do not look back. It will be a little hard at the beginning but good at the end. Cheers
-- Miguel Cobá http://miguel.leugim.com.mx
participants (10)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Damien Cassou -
Lukas Renggli -
Marcus Denker -
Martin McClure -
Miguel Enrique Cobá Martinez -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse