A last word on arrays? Hah!

[Wayne Throop]

I do have comment on John Rose's proposals.  But first...

John Rose uses a posting of mine as an example of error.  We all know
how painful *that* can be, and I hate it whan that happens.  However, I
would like to point out that John's example is *not* the error he thinks
it is.

> [it is an error to say that]
>   array name == 1st elt address:
> [an example of this error is]
>     From: throopw at dg_rtp.UUCP (Wayne Throop)
>     The notational convenience is that an array name "means" the address
>     of the first element of the array.

The fact that in some cases, as a notational convenience, C takes array
names to mean the address of the first element of the array does *not*
imply that "array name == 1st elt address", and I never said it did.  I
clearly stated that this is a notational convenience, and I think most
people take notational conveniences to be special cases, despite the
fact that this "special case" covers most of the uses of array names.  I
am fully aware, and always have been (well, since first reading K&R
anyhow), that C arrays are not pointers, and array names do not always
"mean" the first element's address.  So there.


On to comment on Rose's proposals.

> [ Is this a dead horse or a sleeping dog? ]

It's a dead dog.  Which has more lives than a barnyard full of cats.

>         (1) Allow `&' applied to arrays.  Semantics must agree
>             with the implicit addressing which occurs when an array
>             is the first element of a larger array, and the larger
>             array name is used as a pointer.

This is fine, this is all well and good.  I object to the fact that it
introduces another glitch.  An accumulation of such glitches makes
things less and less comprehensible, not more and more.  Where we now
have "array names in an expression evaluate to the address of the first
element, except when the object of sizeof", we get something like "array
names in an expression evaluate to the address of the first element,
except when they don't".

In my opinion, the increased confusion of "have I enumerated all the
exceptions yet?" makes the usefulness of the notation questionable, and
in the limit of feeping creaturism, worthless.  Saying "well, it's only
*two* exceptions" doesn't help much, as more are coming in proposals
(2-4), and even this one exception is of questionable use.  I'd rather
have ANSI mandate that a cast of the array name to an
address-of-that-array-type is guaranteed to work.

Don't get me wrong.  I'd *like* to see arrays treated more like other
variables, and be able to "&" and "=" arrays.  In some sense, I am
playing a devil's advocate role here, since I wouldn't be horrified to
see &array allowed.  But the array-is-rvalue convention is so entrenched
that I doubt it would really help, hence my countersuggestion on how to
utter "address-of-array".

>         (2) Allow `=' applied to arrays.

Ugh.  This is much worse.  Now evaluation of an RHS depends on what you
are going to assign it to.  Already the case you say?  Nope, the
conversions that happen for all other cases are conversions that the
assignment implies *after* the evaluation, not a change in the
evaluation strategy itself.  Gag me with an lvalue.

Also, it is prone to horrible errors, like doing an array assignment
when you thought you were assigning the address of an array to a
pointer.  The more the meaning of arrays is muddied, the more common
such errors will become.  Folks already think that a declaration of
an array means they can assign to it like a pointer... at least lint
and the compiler will wake them up.  Making the assignment legal is just
asking for trouble.

>         (3) Interpret current C practice of converting array arguments
>             to pointers as passing them by reference; make sizeof()
>             work consistently.

Well.  Sizeof is indeed peculiar.  For example,
sizeof(formal_array_name) yeilds your machine's pointer size.  Either it
should yeild the array size as it does for other arrays (and complain
about being applied to a a size-ambiguous formal array), or sizeof of
*all* array names should return your machine's pointer size, just as it
would for sizeof(array+0).  This makes sizeof work consistently, and
doesn't do violence to the entrenched indirection/subscription
unification.

In any event, introducing the notion of implicit by-reference passing to
C raises more problems than it solves, for example the question of
whether there should be an implicit dereference of by-reference formals
as there is in other languages.  And the issue of
indirection/subscription unification is inadequately treated by this
proposal.

>         (4) Allow arrays to be passed as by value.
                [by overloading prototype declarations]

Bleah.  Yet another "it acts like x except in cases a, b, and c, and on
fridays and holidays, except on leap-years when it always acts like y
unless you are north of the permanent-frost line" type of construct.
You propose that prototypes act the same as classical declaration,
except for arrays, and except-except-except.  And just how does one
prototype-declare (as opposed to define) the difference between a
function with by-value array formals and one with by-reference array
formals?  As I say, bleah.


> To summarize:  I've asked for the addition of 4 new features to ANSI C,
> which make arrays into first class objects.  I've argued that
> programmers can be trusted to use good judgements, and that language
> designers should refrain from making them in advance.  I've shown that
> the new features actually fill gaps in the old language, and the
> resulting language has *fewer* features, since there are fewer
> exceptions.  (Next, we go after bitfields.)

To criticize: You have asked for the addition of 4 incompletely thought
out additions to ANSI C, which make arrays even more confusing and error
prone than they already are.  You have argued that programmers can be
trusted to use good judgement in the face of overwhelming evidence to
the contrary, and that language designers should refrain from making
needless restrictions in advance, which is true... but language
designers shouldn't be obtuse either.  You have shown that the new
features plaster over some cracks in the old language, at the price of
making things even more confusing, and while some exceptions were
eradicated, more were introduced.

Again, don't get me wrong... I agree with essentially all of what you
state as general principles, and even some of your examples (such as
regularizing sizeof, though I differ in detail).  But I think that the
addition of these particular features to C as it stands today would not
be the benefit you take it to be.

Yet another don't get me wrong... I'm *not* saying that "lowly junior
programmers make poor judgements, unlike myself in my lofty position of
vast seniority".  Rather, I'm saying that I *like* language restrictions
that keep *me* from making mistakes, and I like languages where error is
more easily distinguished from correctness.  It's just that, in my
opinion, these proposals go in the wrong direction, and that to go in
the "correct" direction necessarily implies breaking existing code
(hence, really a new language).

Good luck with bitfields... I've seen languages with *good* provisions
for them, and C ain't one of them.

> John R. Rose    ihnp4!think!rose
--

"Actually, it's a buck-and-a-quarter-quarter staff,
 but I'm not telling *him* that!"
-- 
Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw