Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!shinobu!odin!plasm!lord
From: lord@plasm.esd.sgi.com (the toomlrd)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded operator dot?
Message-ID: <1991Apr6.005036.15992@odin.corp.sgi.com>
Date: 6 Apr 91 00:50:36 GMT
References: <11152@jarthur.Claremont.EDU> <1991Mar11.061204.6023@mathcs.sjsu.edu> <4607@lupine.NCD.COM>
Sender: news@odin.corp.sgi.com (Net News)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Lines: 74

This is about the ongoing discussion of an overloadable 
operator dot.

>In order to understand how this would work, I think that you would have
>to look at the whole proposal.  I'm not sure, but I think that the idea
>is to allow something like:

>	expression.expression


>The bare fact of the matter (as I have said many times) is that "." is
>plainly not an operator (either unary or binary).  It is a selector.


If I had to write down the semantics for the dot syntax, I would
assume two subexpressions.  The type of the right hand expression
would be (essentially) `name'.


As it stands now, C++ has no run-time representation for names.
Consequently, it seems like a big deal to overload dot.  If you
accept my view -- there is no problem.  Its just that all the dot 
expressions you've ever seen have had lots of constants.

The extension I would imagine for . will not really expand the concept,
just remove restrictions about what can be done at compile time
vs. what can wait till run-time.

>In effect, dot acts a bit like the other "scope opener" that we know
>about in C++, i.e. the colon-colon.  These things are plainly NOT
>operators.  People who are just learning the language (as well as
>experienced users) will just get more and more confused (when trying
>to read code) if we start to bend the "normal" rules regarding what may
>and may not be overloaded (or treated like an operator).

The advantage of the view I suggest (first class names) is that
the resulting language has fewer, though more general rules.

>I have previously noted that allowing overloading for "." makes about as
>much sense as allowing overloading for "{".  In both cases the very
>idea appears ridiculous, however I actually read a response from one
>person who said that (maybe) allowing overloading for "{" would be
>a useful and good thing!!!

Funny you should say that.  Syntacticly, I hope there will never be
an operator { -- in fact, it takes a few translations before blocks
look like functions at all.

On the other hand, blocks are objects with definable types and
run time representations.  Why not let users define some of the
functionality normally implicit in blocks?  This leads to many excellent
programming techniques usually impossible in C++.


>I guess the bottom line is this.  What is your opinion regarding how
>a language should be designed?  Should it be an unbridled, nonsensical
>and chaotic mismash of random "bright ideas" which seem like they might
>occasionally have some obscure usefulness, or should there be some
>rules, some guiding principals, and some *consistancy* in the set of
>features provided by a language?

There are fewer computer languages than people like to think.  A lot
of languages that seem similar to C++ really are and if you build
clean semantic models of them you see that most bright language ideas
capture special cases of an almost universal semantics and give them
special names.

My conclusion is that what you (the original poster) means by
language design is really syntax design.  Here the issues are much
less `what is the meaning of programs, what programs are possible'
much more `which meanings are used most often, and how are those
uses best expressed?'.

-t