🚀 go-pugleaf

From article <7006:Nov620:42:3990@kramden.acf.nyu.edu>, by brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
> In article <5073@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>> |>       x(1,:) = x(2,:)
>> |   [ easy to see that there's no aliasing ]
>> |   [ C version it's much harder, especially with the rows flipped ]
[...]
>> However, the context of this discussion is whether to use arrays or
>> to use pointers _instead_.
> 
> Exactly. That's why your example has nothing to do with this discussion.

It has everything to do with the original context of this thread, as
Dan very well knows.  The issue was whether C-like pointers were more
efficient than Fortran-like arrays.  The above example can be cast in
that form.

> It should convince people that array slicing and array copying are
> useful features. I don't think any programmer is going to replace a
> single language builtin (such as x(1,:) = x(2,:)) with a series of
> statements, unless he's done some extensive tests showing how poorly the
> compiler handles the builtin.

That's not the point.  The code (in existing languages) would
have to be written as:

   Modula 2                     C
      for i := 1 to N do           p = &x[1][0]; q = p+N;
	 x[1,i] := x[2,i]          for (i=0; i<N; i++)
      end;                            *p++ = *q++;

(Modula 2 this time - I did Fortran last time.) The pointer/C version is
still be harder for the compiler to optimize.  To be sure, the smart C
compiler would be able to find the fact that this is a disjoint row
switch (but with your distrust of complicated optimizers, I would think
you would want to avoid forcing this).  It is still easy in the Modula
loop to tell that the rows are disjoint - but it wouldn't be if the
array notation were preprocessed out (as Dan suggested in the article
from which I began this thread).

J. Giles