Proposal3: Make $_ a valid identifier character

Stefan Matthias Aust sma at 3plus4.de
Sun May 28 17:39:49 UTC 2000


PROPOSAL

For better ANSI compatibility, I propose to allow _ (actually it's printed 
as <- with the default font in Squeak) in identifiers.

These are valid identifiers:

   _ab
   ab_
   a_b

These are valid symbols

   #_
   #_abc
   #abc_
   #_:
   #abc_:

(#_ already works, but that's probably just a bu^H^Hfeature)


BACKWARD COMPATIBILITY ISSUES

This one is tough.  Currently, $_ is used as assignment operator.  ":=" is 
a valid alternative, but nearly every method in the system uses "_" and 
probably a lot of people prefer this over ":=", even if the latter has the 
advantage that it works with standard-ANSI fonts.

It would be however trivial, to automatically change all methods to use 
":=" instead of "_".  The only case where this fails might be places where 
code is constructed from string and then compiled.  However, only that 
strange, dreaded Morphic player stuff uses this feature I think.  So I 
don't care :-)

Here's want I'd suggest:  A previously valid assignment

abc_abc

is declared illegal.  The assignment operator now must be to be surounded 
by spaces or other syntax characters.  So

abc_12

is now interpreted as

abc_ 12

(probably illegal) and not as

abc := 12

Fortunately, the current image already uses the convention to add a space 
before and after an assignment operator in nearly all places.  Once one has 
a small piece of code to locate these cases, it should be easy to fix.

Furthermore, only code that needs to be recompiled is affected, so even if 
we overlook some places, it doesn't break the system (it might break the 
pretty printer, though).

Now, the single identifier _ is declared illegal - opposted to 
ANSI.  Hopefully, nobody really want to call a variable or unary method 
simply "_".

This allows us to still treat _ as assignment for backward compatibility.

We might want to add a switch (Smalltalk ansiConformance, Smalltalk 
ansiConformance: aBoolean) which answers whether we want strict conformance 
or better the backward compatibility workaround.


ADVANTAGES

ANSI conformance as well as conform with VisualWorks, Dolphin ST, VisualAge 
and probabyl also other Smalltalk systems.  Well, not 100% conformance but 
hopefully close enough to easily convert existing code to Squeak.

IMPLEMENTATION ISSUES

Doable.  A year ago or so, I did this change (and posted it even to this 
list) and I can probably dig out that code.  It's again a scanner issue.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf





More information about the Squeak-dev mailing list