[Pharo-project] Underscores question

Bill Schwab BSchwab at anest.ufl.edu
Tue Jan 6 10:29:43 EST 2009


Gwenael,

This might be it.  I thought there was a little more to it, but 

   c_a call: b.

and the interpretations (number list) might be what I was remembering; I
thought it were a few other concrete examples.  There are other parts of
the thread that seem very familar.

My own take is that the default should be to treat underscores as a
letter, and to allow file-in of code with underscore assignment as an
option.  That helps with external interfacing, cross-dialect
compatibility, and retains access to existing/older code.

I do not like Burt's idea of a class method #allowUnderscores, because
(I think??) it assumes _ will not appear in class names, which would be
very helpful in mapping external names to classes.  However, a global
variable could work.  However, I still see underscore assignment as
something that should be supported only when filing in code that uses
it.

Sorry I didn't find more.

Bill



============================

Gmane   	
From: Bert Freudenberg <bert <at> impara.de>
Subject: Underscores in Identifiers (was: Re: Random and unsolicited
feedback on 3.9a)
Newsgroups: gmane.comp.lang.smalltalk.squeak.general
Date: 2005-11-19 10:58:23 GMT (3 years, 6 weeks, 6 days, 10 hours and 10
minutes ago)

When dealing with low_level_code, I'd love to have underscores in  
identifiers - not even just method names, but for variables, too.  
This could probably be achieved simply by using a different type  
table with $_ being an #xLetter in Scanner (not sure about the SmaCC- 
based Compiler).

However, I would also strongly suggest *not* to allow this as a  
standard. Apart from breaking old code file-ins, we would soon get  
tons of unreadable gibberish by C-trained newbies ;-)

Instead, when filing in, the compiler would interpret underscores as  
assignment, just as it is now. *Only* if specifically enabled by the  
filed-in code would it be switched to allow underscores in  
identifiers. Same goes for normal development - *unless* a class  
answer true when asked #allowUnderscoresInIdentifiers, underscores  
are compiled as assignments. The file-out code would take that into  
account to generate the code snippet enabling underscores in  
identifiers needed for later file-in.

How does that sound?

- Bert -

Am 19.11.2005 um 01:39 schrieb Andreas Raab:

> Can we please consider the consequences of doing that (like  
> potentially breaking lots of code from fileIns) and how we are  
> going to deal with it *before* such a change gets included? I would  
> hate it to have another one of those situations where things break  
> for absolutely no good reason.
>
> Cheers,
>   - Andreas



============================

Gmane   	
From: Andreas Raab <andreas.raab <at> gmx.de>
Subject: Re: 3.9 underscore still there?
Newsgroups: gmane.comp.lang.smalltalk.squeak.general
Date: 2006-10-30 20:18:13 GMT (2 years, 9 weeks, 5 days, 6 hours and 46
minutes ago)

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



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

Email: bschwab at anest.ufl.edu
Tel: (352) 273-6785
FAX: (352) 392-7029





More information about the Pharo-dev mailing list