3.9 underscore still there?

I *thought* I had read that the use of the underscore for assign  
symbol had been expunged and all the code converted to use := but  
whilst looking at the compiled method source pointer stuff I noticed  
an awful lot of underscores still around. Is this a mistake or an  
unexpected reversion ?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: RDL: Rotate Disk Left

Tim,

===================
I *thought* I had read that the use of the underscore for assign
symbol had been expunged and all the code converted to use := but
whilst looking at the compiled method source pointer stuff I noticed
an awful lot of underscores still around. Is this a mistake or an
unexpected reversion ?
===================

I don't know that I ever caught a final statement on it, but there
appeared to be problems with the removal.  First, there were troubles
identifying comments and literals[*], and either related to the first
snag or independently troublesome, I thought I read of widespread
badness after the "fix".

My interest in underscores is mostly to enable them to appear within
selectors.  There is a fix for underscores at all but the first slot
(which almost completely fixes the problem for me), and I would like to
see it in the mainstream image if we can't fix the real problem.  I had
hoped that the fix would no longer be needed courtesy of m17n, but that
appears not to have happened yet.

[*] Could the RB help?

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

"Bill Schwab" <[hidden email]> writes:
> My interest in underscores is mostly to enable them to appear within
> selectors.  There is a fix for underscores at all but the first slot
> (which almost completely fixes the problem for me), and I would like to
> see it in the mainstream image if we can't fix the real problem.  I had
> hoped that the fix would no longer be needed courtesy of m17n, but that
> appears not to have happened yet.

There is a lot of legacy code not even in the image that uses
underscore for assignment.  Please allow this code to keep working.
We should not break massive amounts of code just for legacy reasons.
At the very very least, allow such legacy code to file in.

If you or anyone have a parsing hack you would like to try, e.g. to
allow it in identifiers while still allowing it for assignment, a
great sample set would be the 3.7 stable universe.  This is 200
packages worth of Squeak content, quite a lot of which uses _ for
assignment.  If your idea works there without breaking anything, then
it is probably okay.

The download is here:

    http://minnow.cc.gatech.edu/squeak/3835

-Lex

Lex,

First, the 3.7 stable universe idea is a good one.

Asking me to allow the old code to run is an odd way to put it: I have
absolutely no power over it.  However, it might be interesting to see
how much of that code passes even a basic smoke test.  I might be
pleasantly surprised, but given the complaints I have read over time re
things like the Canvas protocol[*], I suspect that much of the code is
broken over far worse things than underscores.

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.

I disagree with your assessment that I am suggesting a change for legacy
reasons.  Quite the opposite.  I am suggesting it for compatibility with
other dialects and ANSI compliance.  I submit that yours is the legacy
argument.  And it is one legacy of Squeak which should not be
celebrated.  Hijacking the underscore for single-character assignment
was a mistake; the same capability could and should have been provided
within the editor, keeping the compiler and sources clean.  Please allow
that to be corrected, albeit at a pace that keeps associated discomfort
to a minimum.

Sincerely,

Bill


[*] I'm simply stating that my imperfect memory of unmoderated comments
gives the impression that it has been a moving target.  The less
accurate that statement is, the happier I get - within reason.


Lex Spoon:

There is a lot of legacy code not even in the image that uses
underscore for assignment. Please allow this code to keep working.
We should not break massive amounts of code just for legacy reasons.
At the very very least, allow such legacy code to file in.

If you or anyone have a parsing hack you would like to try, e.g. to
allow it in identifiers while still allowing it for assignment, a
great sample set would be the 3.7 stable universe. This is 200
packages worth of Squeak content, quite a lot of which uses _ for
assignment. If your idea works there without breaking anything, then
it is probably okay.

The download is here:

http://minnow.cc.gatech.edu/squeak/3835





Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

"Bill Schwab" <[hidden email]> 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.



-Lex

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: [hidden email]
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

Andreas,

My interest in Squeak is more strategic than tactical.  Windows scares
the willies out of me, and I feel obligated to look for a cross-platform
home for me and my cash cows.  Squeak has enough going for it that I
find it difficult to simply walk away.  The big points of concern are
relatively little things like underscores (that are unfortunately shoved
down my throat from outside), lack of error on read stream
exhaustion[*], printing might be a problem (haven't gotten that far
yet), and the ever present concern about what users would say about the
feel of the morphic GUI.  I also make some important use of Dolphin's
overlapped calls, but that is more on the research (me being the user)
side.  Knowing that the morphic feel would be a complete disaster, and
because I think I can help, I have started pressing there.

Bill

[*] I would much have have #next: blow up when I ask for non-existent
data than to worry how far a nil might get before it is recognized.



Andreas Raab:
> 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.




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029