Lex,
My preference would be for ANSI compatibility. With that said, having underscored in selectors, and even just all but the first slot, would do almost everying I need. I doubt I use them in variable names, and if I do, I could change it. If I were to move my production code to Squeak, I would be editing a lot more than a few variable names. Most of uses of underscores are matching the outside world, and that is not so readily altered to suit my whim or Squeak's limitations. If we can get Ian's fix in the mainstream, it would be greatly appreciated.
Bill
Lex spoon:
"Bill Schwab" <BSchwab@...> writes:
Please keep in mind that my most emphatic request is to promote Ian's
(I
believe) fix, for underscores in all but the first slot in a
selector,
to part of the mainstream release so that it will get maintained as
the
compiler evolves. I am not aware that it breaks any code.
That kind of thing would sound great to me. The stable universe provides a good test for this theory, if anyone wanst to do that test and lend support to the underscores cause.
By the way, do you only mean selectors, or also variable identifiers? What would the proposal do about this kind of code?
x_3 "is it x := 3, or the identifier x_3 ?"
I disagree with your assessment that I am suggesting a change for
legacy
reasons.
That was a typo; indeed, I am the one arguing that we support our legacy. I am happy to support the ANSI standard if possible, but I would put the top priority on existing Squeak code.
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bills@anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
Bill Schwab wrote:
My preference would be for ANSI compatibility. With that said, having underscored in selectors, and even just all but the first slot, would do almost everying I need. I doubt I use them in variable names, and if I do, I could change it. If I were to move my production code to Squeak, I would be editing a lot more than a few variable names. Most of uses of underscores are matching the outside world, and that is not so readily altered to suit my whim or Squeak's limitations.
If all you want to do is to get your code going in Squeak, a fairly simple alternative is to subclass the current parser/compiler, apply Ian's patch and use those for loading your own classes. It ain't exactly a great solution but may be helpful in the short term.
If we can get Ian's fix in the mainstream, it would be greatly appreciated.
This is one of these situations where a little more thought is in order because there are both short-term and long-term implications. Consider an example like this:
c_a call: b.
Depending on the interpretation of underscore we have 3 possibilities: 1) Underscore means assignment: The above is a legal expression. 2) Underscore is a letter: The above is a legal, too. 3) Underscore is a letter in selectors except if first, and invalid for variable names: The above is illegal.
So in two out of three interpretations the above is legal, only in the last one it is not. What troubles me here is that while it may be an okay solution in the short term to put the burden on the user of the underscore (e.g., basically saying "if you use underscores you need to understand where exactly you can use them and where not") the inconsistency and complexity inherent in the description that "underscores are treated as letters in selectors unless they are the first character and cannot be used in variable names" strikes me as a *very* poor choice in the long term.
I'd rather do something where (based on some meta-annotations) the parser can decide whether to to treat underscores as assignments or as letters and possibly rewrite them on the fly. The essential idea being that legacy code (using underscore as assignments) can still be loaded into a later version.
Cheers, - Andreas
squeak-dev@lists.squeakfoundation.org