Dear Squeakers,

below is a 'meta' comment:

Bijan Parsia wrote:
> 
> On Tue, 30 May 2000, Richard A. O'Keefe wrote:
> 
> >       Richard, you misunderstood me. I questioned that the *reason*, the
> >       *motivation*, for Smalltalk not having underscores in identifiers was that
> >       ASCII lacked them, not that ASCII lacked them.
> >
> > I already *asked* in this thread whether anyone who was there at the time
> > knows about this.
> 
> So point me to your received answer which allows you to state, with the
> absolute confidence that you do, that the *original* reason for not
> including the underscore, *and* the reason for it not being included in
> Smaltalk-80, was it's original unavailibility in ASCII. I'm prepared to
> believe it, obviously, but only with some suitable confirmation.
> 
> >       Given that Smalltalk developed on computers custom built, and mostly
> >       intended for internal use, I find this is touch hard to believe. A
> >       reference would be welcome.
> >
> > However, I'd put it the other way around.  The identity of the old Smalltalk
> > character set with old ASCII is too much of a coincidence to accept as the
> > result of some special Smalltalk decisions, especially since the Blue Book
> > (p650) refers to the keyboard delivering ASCII codes (when ALTO codes were
> > also available).  We're told on p114 of the Blue Book that
> > "Each [character] is associated with a code in an extended ASCII
> > character set".  So how come the *only* non-ASCII characters shown in
> > the Blue Book are *precisely* the old versions of the two ASCII characters
> > that are *not shown*?  Presumably if they were inherited from old ASCII,
> > and the extensions were other characters again.
> 
> Nice speculation. But, while plausible, it doesn't establish your
> case.


Who cares for the present time?

I think it would be better to concentrate onto the current problems and
to avoid history wars and fights in the spirit "I'm right, you are
wrong!" ... ;-)

>From 'Transaktionsanalyse' ('transaction analysis' in English?): The
only constructive approach is
	"Your are OK, I'm OK."

Greetings,

Stephan

> 
> >       For the record, I don't think your linguistics based argument is nearly as
> >       air tight as you seemed to thing it was. I notice you didn't say a word
> >       about the fact that I take "multi word" identifiers to be single words,
> >       not collections of them.
> >
> > Well, that's a rather unusual way to view them.  My native language (English)
> 
> It's my native language too.
> 
> > is not an agglutinating one, so it's practically impossible for me to
> 
> Well, one of us must be horribly idiosyncratic. Which, regardless of
> issues of taste, makes us, without establishing which of our
> psycholinguistic structures is deviant (and they *both* could be), bad
> bases for determining what, rationally speaking, should be the case here.
> 
> > mentally process multi-word identifiers as single "words", just as it's
> > very hard for me to hear "r" and "l" as vowels.
> 
> So you have trouble with 'groundhog'?
> 
> [snip]
> >       Furthermore, I didn't see anything above about
> >       the linguistic data on the superiority of $- to $_ as separators.
> >
> > I don't have any.  I'd expect the hyphen to be the winner.
> > Lisp gets away with it because it doesn't have any infix operators.
> > None of the Fortran family (Fortran, Algol, Pascal, Ada, ...) has
> > adopted hyphen as word separator, not that I know of, and for the
> > obvious reason that it would be ambiguous with infix minus.
> 
> Others have pointed out the infix _ in Squeak as it stands, and the
> possibility of distinguishing the minus and the hyphen.
> 
> Needless to say Sequencable-Collection is still very bad, IMHO. But, let
> us not debate this further.
> 
> [snip]
> > So would I.  However, I note that the fact that Sequenceable_Collection
> > is visibly broken into chunks seems to make it easier to see and check
> > each of the chunks.  There was so _much_ text in one great fat lump in
> > "SquencableCollection" that it was hard to see the typo.
> 
> Which is why the lovely correction facilities of a Smalltalk IDE make life
> so much easier. Sicne I ma prune to tipos evan in spcede dilminted words,
> I don't take this is as at all decisive.
> 
> >of course, we might just look at extant bodies of Smalltalk code with and
> > without $_ed indentifiers. That might provide a few clues.
> >
> > Given the existance of a free VisualWorks and a free Squeak, it might
> > actually be possible to _do_ such experiments.
> 
> Of course. Realize that my strong opposition stems from engaging to port
> some Smalltalk code which made fairly heavy use of _s from VisualWorks to
> Squeak. The indentifiers which used _s tended to, imho, pointlessly to do
> so. The indentifiers were bad in themselves (imho) and the underscores
> merely...er..underscored that fact.
> 
> A fully underscored set of indentifiers would not recognizably be
> Smalltalk. Nor would a fully hyphenated one. It might *be* Smalltalk, but
> it would be difficult to recognize as such. I think that is a
> consideration against full underscoration. I know you do not, so I'll let
> it drop here.
> 
> > What would be particularly interesting to know, of course, would be why
> > some of the more commercial (NOT the same as more valuable!) Smalltalks
> > have already made the transition.
> 
> I'll have to see if the draft ansi spec has a rationale for this. I'll
> note that AFAICT, systematic underscorification doesn't seem to have
> occured.
> 
> Cheers,
> Bijan Parsia.

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3