Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Pointers as 3-tuples
Message-ID: <14333@lambda.UUCP>
Date: 11 Apr 90 06:02:45 GMT
References: <296:Apr1105:06:4490@stealth.acf.nyu.edu>
Distribution: usa
Lines: 40

From article <296:Apr1105:06:4490@stealth.acf.nyu.edu>, by brnstnd@stealth.acf.nyu.edu:
> In article <14327@lambda.UUCP> jlg@lambda.UUCP (Jim Giles) writes:
> [...]
>> Multidimensional arrays
>> are NOT arrays-of-arrays.  The subscripts of a multidimensional
>> array are independent and carry _equal_ weight.
> Both assembly code and mathematics say otherwise: at some level of
> specification (the opposite of abstraction), a multidimensional array
> really is an array of arrays. I agree, the user often doesn't think of
> it that way; but it's still the truth.

Who cares about what assembly code does?  It is the purpose of a high
level language is to present an environment that is relatively free
from such concerns.

Mathematically, what you say is not true.  The ordering of subscripts
is an arbitrary decision by the mathematician who lays out the calculation.
Mathematically, such operations as TRANSPOSE are regarded as 'feebies'.
The level of specification you are refering to is _below_ that at which
mathematics works.  Certainly such concerns as row- vs. column-wise
storage are (rightly) regarded as irrelevant to the user.  The only
time such concerns become important is when efficiency forces them
into the limelight. Even in this case, an implementation which
_efficiently_ handles such details is preferable to one which
requires user intervention.

> [...]
>> > 	INTEGER A(10)
>> > 	CALL PROC(A,A)
>> Not necessarily broken.  Only if PROC modifies one or more of its
>> arguments.
> Note that Fortran has no way to express that concept explicitly, while C
> can declare const int *A. Hmmm, shall we start flogging this horse too?

Why not?  I _support_ the addition of an explicit way of declaring which
procedure arguments are changed and which are not.  I am NOT and Fortran
fanatic.  I don't maintain that it is perfect or even nearly so.  In this
case, I would rather deal with Fortran's shortcomings than with C's though.

J. Giles