Hello,

> > And in new code, those who like to assign with underscores with no
> > whitespace around them, can even continue doing so, as long as they don't
> > have x, y, and x_y in scope, which might well mean that they will never
> > write an unintended ambiguity in their entire careers. Should it happen
> > anyway, a simple space will suffice to clear things up.
> 
> It's not just a matter of new code. It is possible that a re-compilation of 
> old code would happen.

  One thing we could do is:

  1. Use m17n package.

  2  Make the left arrow (U+2190) legal assignment syntax.

  3. Fix the existing glyphs so that the 16r5F character is shown as
     an underscore.

  4. Hack the ParagraphEditor so that we can enter underscore and left
     arrow without any OS support.  (This should be as easy as the
     mechanism I wrote in the response to Darius.)

  5. Come up with new file out extensions.  (Somehow I'm thinking .csm
     and .stm. would be ok.)

  6. When a .st or .cs file is loaded, the 16r5F characters in it (but
     not in the string constants) are converted to left arrows.  When
     .csm or .stm is loaded, it doesn't do this.  (The rationale is
     that the 16r5F characters in the old files were indeed left
     arrows.)

  7. Convert all methods in .changes and .sources so that the
     underscores get converted to left arrow (U+2190).

  8. Make 16r5F character an legal character for names and make it
     illegal as assignment character.  (So, until this point, we still
     can't use the underscore in part of the names.)

  The upside of this strategy is that we can support existing stuff in
the base image and out of base image.  Also, we can let programmers
use both ':=' and the left arrow for the assignment syntax.  The down
side is that it'll change the .sources at some point; it has to be
done when we change the major version.  (While we are at 3.x versions,
we can move to #6 in the above list.)

-- Yoshiki