Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!mordor!sri-spam!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.lang.c
Subject: Re: Conformant Arrays in C
Message-ID: <1988Feb29.143422.13969@light.uucp>
Date: 29 Feb 88 22:34:19 GMT
References: <42529@sun.uucp> <7297@brl-smoke.ARPA> <676@cresswell.quintus.UUCP> <1988Feb24.165307.4938@light.uucp> <694@cresswell.quintus.UUCP>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: Light Systems, Mountain View, CA
Lines: 68
Keywords: ANSI C, C++

In an earlier article I wrote that multi-dimensional arrays are best
left out of ANSI C and for C++.

Richard A. O'Keefe <ok@quintus.UUCP> responded:
>I am sorry to blaspheme against anyone's religion, but IHMO, C++ itself
>is an unneeded hack.  Well, add a smiley to "unneeded", but "hack" I am
>serious about.  C++ is the Fortran 8X of object-oriented languages.
> ...
>It is only too credible that conformant array parameters may not be the
>best way of achieving the goals of
>  o minimal change to the language and implementation
>  o making it straightforward to write functions with multidimensional
>    array parameters
>  o avoiding over-specification, so that intercallability with other
>    language is not impaired more than we can help
>But it is CERTAIN that Bakul Shah's suggested alternatives
>> Why not use C++ or Chris Torek's idea for new code?
>do not meet those goals.

Somewhat different set of goals make sense to me.

1.  Avoid any extensions to C at this point -- this would only delay the
    the standard.  Conformant array parameters or any other means of
    making multi-dimensional arrays a first class object would be a major
    extension.  Leave such extensions to a successor language (I used C++
    in this sense, as an *example* -- I don't care to join a discussion
    of whether C++ is an abortion or an immaculate conception).

2.  A successor language, call it NEXT(C), should first clean up C and
    provide a more regular set of features.

3.  For NEXT(C) minimal change is not as critical as making all new
    features orthogonal (to get maximal use out of a minimal number of
    features).  Conformant array parameters extension may be *minimal*,
    it certainly isn't as orthogonal as some other mechanisms.

4.  Do not standardize a new feature until you have implemented and used
    it for a few years.

Related topics of
    o  what KIND of features should go in NEXT(C),
    o  whether NEXT(C) should be upward compatible to C or a *subset* of C,
    o  whether NEXT(C) should be a high level assembler (like C) or allow
       data abstraction facilities (like CLU does), and,
    o  whether C++ fits the bill or not
warrant further discussion, separate from this one.  I bring up NEXT(c)
mainly to point out that it will be a better language to add MD arrays
(multi-dimensional arrays -- sorry, I can't think of a better name).

In C there ARE some ways of implementing functions that take MD arrays.
They may not be pretty but will get the job done.  In my previous article
I used Chris Torek's proposal as an *example*, not as the *right* way to
implement MD arrays.  Besides, in a modern language you would want more
than one representation for MD arrays.

BTW, MD arrays in C++ using a variation of Torek's idea is *not* an over-
specification.  It is just another piece of useful code, not an extension
to the language.  Now if someone proposed legislating it as the only way
to do MD arrays in C++, I would be very surprised and definitely fight it.

Intercallability is not an issue since an MD array can be mapped one-to-
one from one language to another but you will need some glue in some
cases; even Pascal and Fortran are not intercallable without some glue.
But compatibility with Pascal's conformant array parameters can not be a
desirable goal -- conformant arrays are a hack in *any* language!

-- 
Bakul Shah

..!{ucbvax,sun,py