Must _ go like the Dodo?

Jarvis, Robert P. Jarvisb at timken.com
Tue Mar 16 13:52:33 UTC 1999


> <two-cents-worth>
> Personally I like both the _ (or <- for the ANSI-challenged) and the ^
> glyphs.  I think they're clean and clear, and they give Smalltalk some of
> its flavor.  To me "flavor" is important - if I wanted to code in C I'd do
> so (and still do now and then).  Smalltalk is an excellent language,
> esthetics-wise, and screwing with it to (for example) free up the
> underscore character (what's so great about underscores?) for use in names
> or to make things more C-like is, in my opinion, not a Good Thing.  If
> there was any move to replace the ^ glyph with a textual word it should be
> 'answer', in my opinion.  That's how I read that glyph, e.g.
> 
> 	^something
> 
> is read as
> 
> 	answer something
> 
> NOT
> 
> 	return something
> 
> In some people's minds this is, perhaps, a nit, but to me its an important
> nit.  Changing Smalltalk to be more C-like so beginners are happier is not
> something I find particularly compelling.  No flames intended, just an
> (unasked-for) opinion or two.
> 
> Pax.
> </two-cents-worth>
> 
> Bob Jarvis
> The Timken Company
> 
> -----Original Message-----
> From:	Peter William Lount [SMTP:paradigm at unixg.ubc.ca]
> Sent:	Tuesday, March 16, 1999 12:26 AM
> To:	Squeak Mail List
> Subject:	Re: Must _ go like the Dodo?
> 
> Hi,
> 
> I would like to use "_" as a normal character. I won't miss it as an
> assignment statement.
> 
> I learned smalltalk when "_" (or approx. "<-" for the onscreen glyph) for
> assignment was all there was. I didn't like ":=" at first, but then I
> didn't like looking at "_" on print outs and in non-smalltalk code editors
> either. I prefer ":=" now and always change code that uses "_" into a ":="
> as a matter of good coding style. It's just easier to read and I find that
> people who know other programming languages feel ":=" to be more familar
> to
> them than "_".
> 
> Besides the onscreen glyph for the left arror assignment operator should
> not have been mapped to the underscore character in the first place. (I
> wonder why it was choosen? Just because the underscore is the closest to
> the left arror assignment character? Anyone know?). 
> 
> Unlinking the left arrow from the underscore character will free the
> underscore character from years of being forced to impersonate another
> glyph. ;--)
> 
> What is needed is another character that can be generated from the
> keyboard
> for the left arrow assginment. But it's too late for that since other
> Smaltalks have already adopted the ":=" as the assignment character.
> 
> I also find that a lot of people just learning Smalltalk have a difficult
> time with the return symbol "^". Maybe it should be replaced with the
> keyword "return" as in "return anObject" in place of "^anObject"? This
> would make the language a little more familar to all those crazy and wacky
> "C" and "C++" programmers out there! ;--)
> 
> All the best,
> 
> Peter W. Lount
> peter at smalltalk.org
> 
> p.s. Caution while reading. This email contains highly combustable
> material
> that might ignite into flames. ;--)
> 
> ----------
> From: Dan Ingalls <DanI at wdi.disney.com>
> To: squeak at cs.uiuc.edu
> Subject: Re: Must _ go like the Dodo?
> Date: March 15, 1999 8:45 PM
> 
> >>I think this is the way to go.  I would not try to deal with a minus
> sign
> >>here, but underbar should be usable when we drop the old assignment.  [I
> >>don't plan to do this until v3.0 because it implies a change of the
> >>sources].  I have been wanting dotted global names for quite a while.
> >
> > ... many near-flames snipped...
> >
> >Long live _ !
> 
> Folks -
> 
> I couldn't care less about _, except that I have heard a lot of reasons
> *from people on this list* for wanting to use _ as a normal character and
> not for assignment.
> 
> What I said above means we won't do it right away, not we're planning to
> do
> it soon.  Jeesh.
> 
> Was there anything else of interest in those messages?
> 
> 	- Dan





More information about the Squeak-dev mailing list