Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!julius.cs.uiuc.edu!apple!agate!usenet
From: deadman@garnet.berkeley.edu (Ben Haller)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C Suggestions
Message-ID: <1990Oct9.081754.23078@agate.berkeley.edu>
Date: 9 Oct 90 08:17:54 GMT
Sender: usenet@agate.berkeley.edu (USENET Administrator)
Organization: Stick Software
Lines: 80

In article <1990Oct9.020415.16763@eng.umd.edu>
russotto@eng.umd.edu (Matthew T. Russotto) writes:

> In article <1990Oct8.154744.15837@nntp-server.caltech.edu>
> palmer@nntp-server.caltech.edu (David Palmer) writes:
>
>> Here's a suggestion for the next 'Think C'.  Allow the operator '->>' to
>> dereference handles, just as '->' dereferences pointers.
>
> No, instead as minus shift right.

  I can't think of any situation in C where ->> would be a meaningful
construct.  Minus shift right is not legal - you need an operand in there.
Minus and shift right are both binary operators (sure, minus is unary too,
but then its operand comes after the '-').

> If you make a smart compiler, you can recognize handles to structs and
> add the extra de-reference automagically-- I'd like to see that

  Myself, I think both of these are very bad ideas for several reasons.
I'll deal with the ->> first...
  This one has an initial attraction.  But language design is very tricky.
I wouldn't want this implemented unless I was *sure* that it didn't
introduce any lexical ambiguity at all into the language.  This is not such a
simple thing to be sure of.  I don't *think* it does, but do I *know*?  And to
be sure of this in C++, with operator overloading, is even harder, it seems
to me.
  If there were any lexical ambiguity, either certain C constructs would be
less functional than they were, or the ->> operation would only work
sometimes, or something.  It would be bad, and it would cause K&R and
ANSI-correct programs to compile incorrectly or at least produce compiler
errors unless it were done very carefully.  There's a good reason why language
design is considered hard.  To implement a feature like this on a whim is a
very poor idea.
  Now for having the compiler automagically double-dereference handles if
it seems like what the programmer wants.  First of all, I think this is
a terrible idea just because it would make handles virtually identical, in
the programming view, to pointers.  Once you never have to double-dereference,
you tend to forget that the thing *is* a handle, and you start treating it
like a pointer.  Then you either end up with memory moving out from under you
and creating crashes, or you end up with a log-jammed heap.  It's very good to
keep the programmer aware of what's happening at a low level.  If this isn't
true, why not just make pointers dereference automagically too?  If you have a
pointer to a structure, just use the '.' operator to reference the structure
elements.  But this is a bad idea for the same reason: it makes a *big*
difference whether you're using a structure, a pointer to struct or a handle
to struct.  If you make the usage of all of these similar, programmer errors
will increase drastically.  Lord knows there's enough memory errors out there
without that...
  Also, as with the ->> construct, I'm not at all sure that you wouldn't lose
some constructs that currently work.  Again, I can't think of any, but I'm not
a language designer, and I have much too much respect for Kernighan, Ritchie
and Stroustrup to think that I can be sure of something like that.
  Now for both of them at once.  I think they're bad because, first of all,
they're nonstandard.  If every compiler in the world had its own neat little
"improvements", it would become meaningless to even talk about the C language.
Having one universal language is very good, and it's one of the best things
about the new ANSI standard for C.
  Second of all (this sort of ties in with the first, but it's somewhat of a
separate issue), they're non-portable.  Either you use them, in which case
your programs can't be ported to another compiler (even on the same
machine...) without going through and rewriting.  Or you don't use them, in
which case why have them (slightly) slowing down the compilation, clogging up
the preferences dialog and adding K to the compiler?  Myself, I don't know
what I'll be doing five years down the road with the code I write today.  I
may be running it on machines that haven't been invented yet.  I don't want to
write machine-specific code any more than I have to, much less
compiler-specific code...
  I think this thread should be limited to compiler features, user
interface, etc.  I think language design should be left to those with
many degrees (or just much knowledge, often possible without many degrees :->)
and a lot of experience.  To try to remake C into your "dream language"
is a really bad idea.  Who knows?  The folks who do THINK C and MPW might
actually be listening, and they might actually implement these ideas, and
we don't want to be sorry if that happens...

-Ben Haller (deadman@garnet.berkeley.edu)
"But it's all right, it's all right / For we've lived so well so long
 Still, when I think of the road we're traveling on
 I wonder what's gone wrong..."              -Paul Simon, _American Tune_