|Anonymous | Login||09-28-2020 23:09 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0005712||[Squeak] ToDo||feature||always||01-09-07 04:00||01-10-09 01:53|
|Summary||0005712: Underscores in selectors|
Allow underscores in selectors for portability and by popular demand.
UnderscoreAmbiguity.3.cs [^] (44,097 bytes) 01-09-07 04:01
UnderscoreAmbiguity.4.cs [^] (43,434 bytes) 01-09-07 05:00
UnderscoreAmbiguity.5.cs [^] (43,395 bytes) 01-09-07 09:50
(0008855 - 587 - 661 - 819 - 819 - 819 - 819)
edited on: 01-10-07 12:19
Discussion page for this issue http://squeak310.pbwiki.com/GoalUnderscoresInSelectors [^]
Methods where underscores are used as assignment need to have underscore delimited by whitespace so as not to confuse the compiler when underscores in selectors are enabled. File, fixes all methods in Squeak3.9-final-7067 where this has been identified. UnderscoreAmbiguity.5.cs has timestamps set to '', to be loaded in conjunction with 0005713
Installer mantis ensureFix: '5713 File in, use old timestamps'.
Installer mantis bug: 5712 fix: 'UnderscoreAmbiguity.5.cs'
(0008863 - 1118 - 1196 - 1196 - 1196 - 1196 - 1196)
This should be done in two steps.
One tests for underscores being used as assignment need to be added to acceptance criteria.
It is important to test pretty printing. OB sets a flag that causes the code scanners to print assignments as unerscores instead of :=.
The ambition of 3.10 should probably be limited to getting these tests to all pass.
When no code uses underscores for assignment and no prettyprinter outputs underscores instead of the assignment operator then the underscores in names should be enabled (and tested).
That should be some future version of squeak depending on when stuff is ready. Also I imagine that the risks involved in getting this to work will require a lot of testing and a plan B just in case things don't go according to plan A.
Also. No attempt should be made to have both underscores in selectors and as assignment characters at the same time. Tring to read and parse that code will get too hairy for a human to follow. (Especially one who is used to reading the old squeak code. And those are the ones you want looking at it.)
Yours in service, --Jerome Peace
(0008864 - 986 - 1022 - 1022 - 1022 - 1022 - 1022)
I disagree, underscores are easily identifiable as assignment, since they occur on their own, and MUST have some whitespace either side. Underscores can be enabled in selectors at the same time because underscores in selectors are always part of a word. They are not difficult to distinguish.
Current problems preventing us from moving forward with underscores have been exacerbated by the desire to migrate large portions of code to the preferred scheme ':=', and the problem of supporting legacy code that uses underscores as assignment.
Therefore I propose that it is necessary and desirable to support both concurrently for a period of transition. If it works it is the quick solution to the fact that underscores in selectors is needed (for porting SSpec and GLORP from VW for example) rather than tackling the whole assignments issue head on.
The pretty printers could also be improved to render an underscore as assignment with a pleasing 'double left arrow' or similar.
(0008865 - 1162 - 1299 - 1299 - 1299 - 1299 - 1299)
01-11-07 03:03 wrote.
I disagree, underscores are easily identifiable as assignment, since they occur on their own, and MUST have some whitespace either side.
Well tell that to the underscores and the pretty printers. I think you'll find a lot of places that have not followed that rule. Personally I learned first on a Forth system so I feel uncomfortable when operators don't have spaces around them. I think that implementing your change is risky and likely to break backwards compatablity. There is still a lot of code out there you can't get your hands on to disambiguate.
This is a design tradeoff decision. You may be right about your idea improving compatability with other squeaks. I can't imagine that anyone else would use underscores for both purposes.
I still think its safer to postpone a risky change and concentrate on a safe one that clears the way and really makes the code unambiguous.
I don't have to choose since the final decision isn't mine.
[OT] We can both have our different opinions.
Differences of opinions are what make for good horse races.
Yours in service, --Jeorme Peace
(0008868 - 985 - 1019 - 1019 - 1019 - 1019 - 1019)
I learned Smalltalk in 1985, so I love the left-hand arrow as assignment. However, underscore (same ASCII character, different font) is just stupid. If Squeak is not going to use the left-hand character as the display format for underscore then IMHO, underscore should be removed as assignment. There is a lot of code that still uses it, so we need to support it for backward compatibility, but we don't need to support it in standard code. Newbies think it is weird for a language to have two assignment operators.
I thought that Stephane Ducasse converted all the underscores to := in 3.9, and am surprised that there are so many underscores left.
I think that we need a change to fileIn that automatically replaces underscore with :=. Perhaps we need two fileIns, one is a "fileIn old format" that does this. Then we eliminate all underscores in the image and allow names to include underscore. Then old code cannot be filed in unless you use the special filein tool.
(0008869 - 85 - 85 - 85 - 85 - 85 - 85)
|Stephane tried, packages failed to load back in, so they had to roll back the change.|
(0008870 - 535 - 607 - 607 - 607 - 607 - 607)
The problem I think is that there is a preference that controls how assignment is printed.
OBBrowser somewhere set it after Stef had done his work.
That undid things as things got printed out.
Then as modifications get resaved the source is back to being underscores again.
It can be fixed with persistance and determination. It just didn't work the first time.
And I am obviously in favor of an unambiguous fix before the enhancement of allowing underscores in variables.
Yours in service, --Jerome Peace
(0009027 - 586 - 644 - 644 - 644 - 644 - 644)
Since one of the motivations is portability, I will note that both VisualWorks and VisualSmalltalk allow for a single underscore to be a unary selector. If Squeak is also to allow this, and to also allow for _ to still be used for assignment, then the following will be ambiguous...
a _ b.
which could mean a:= b. or (a perform: #_) perform: #b.
So a decision will need to be made to either disallow #_ as a selector, OR disallow _ for assignment.
The question also arises as to whether underscores should be allowed within variable names, in addition to within selectors.
|01-09-07 04:00||Keith_Hodges||New Issue|
|01-09-07 04:00||Keith_Hodges||Status||new => assigned|
|01-09-07 04:00||Keith_Hodges||Assigned To||=> KenCausey|
|01-09-07 04:01||Keith_Hodges||File Added: UnderscoreAmbiguity.3.cs|
|01-09-07 04:03||Keith_Hodges||Note Added: 0008855|
|01-09-07 05:00||Keith_Hodges||File Added: UnderscoreAmbiguity.4.cs|
|01-09-07 05:01||Keith_Hodges||Note Edited: 0008855|
|01-09-07 09:50||Keith_Hodges||File Added: UnderscoreAmbiguity.5.cs|
|01-09-07 09:50||Keith_Hodges||Note Edited: 0008855|
|01-10-07 02:14||KenCausey||Assigned To||KenCausey => RalphJohnson|
|01-10-07 02:14||KenCausey||Category||Any => ToDo|
|01-10-07 12:16||Keith_Hodges||Note Edited: 0008855|
|01-10-07 12:19||Keith_Hodges||Note Edited: 0008855|
|01-11-07 02:09||wiz||Note Added: 0008863|
|01-11-07 03:03||Keith_Hodges||Note Added: 0008864|
|01-11-07 09:20||wiz||Note Added: 0008865|
|01-11-07 13:08||RalphJohnson||Note Added: 0008868|
|01-12-07 07:33||Keith_Hodges||Note Added: 0008869|
|01-12-07 09:16||wiz||Note Added: 0008870|
|01-18-07 17:50||tween||Note Added: 0009027|
|05-24-08 18:40||wiz||Relationship added||child of 0006432|
|01-10-09 01:53||Keith_Hodges||Status||assigned => pending|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
94 total queries executed.|
52 unique queries executed.