Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!cornell!uw-beaver!uw-june!uw-entropy!mica!charlie
From: charlie@mica.stat.washington.edu (Charlie Geyer)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <1536@uw-entropy.ms.washington.edu>
Date: 20 Jun 89 01:52:54 GMT
References: <1527@uw-entropy.ms.washington.edu> <13946@lanl.gov>
Sender: news@uw-entropy.ms.washington.edu
Reply-To: charlie@mica.stat.washington.edu (Charlie Geyer)
Distribution: usa
Organization: UW Statistics, Seattle
Lines: 54
Summary:
Expires:
Sender:
Followup-To:


In article <13946@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>From article <1527@uw-entropy.ms.washington.edu>, by 
>charlie@mica.stat.washington.edu (Charlie Geyer):
>> [...] 
>> How about C?  C pointers point to objects.  Pointers that actually
>> happen to point to the same storage location are not required to
>> compare equal and so forth.
>
>C pointers point to _contiguous_ objects - not to arbitrary ones.  Therefore,
>C pointers are just raw addresses (possibly scaled by some type factor).
>This is _not_ the model of pointers that I object to (aside from a generl
>aversion to pointers themselves).  

Not so.  As I said, C pointers point to objects, not to arrays of contiguous
objects.  It is true that if p is a pointer to an object, p+1, p+2, ..., and
p-1, p-2, ..., may perhaps be valid pointers to objects of the same type.
This decidedly does not make them "raw addresses (possibly scaled by some 
type factor)", as you seem to recognize below.

But there is something even more wrong here.  Any C object can be pointed to
by a pointer.  The reason there are no C pointers to array sections in C is
that "array section" is not a C object.  This is not a limitation on the
notion of "pointer" in C, but on the notion of "array", which is extremely
primitive in C.  Pointers, on the other hand, are completely general.

>> Just out of curiosity, why is this "junk"?
>
>You have answered part of that yourself.  Pointers to the same location
>don't compare equal.  This makes it hard to implement even run-time tests
>for aliasing (in case you want to avoid it for optimization purposes).
>Pointing to arbitrary, non-contiguous, objects would only aggravate this
>problem (along with others concerning optimization).

This seems to say that, contrary to what you said above, you _do_ object
to C pointers because "pointers to the same location don't [necessarily]
compare equal".  This is not necessarily a bad thing, as was explained at
great length by many posters (none of them me) in a recent flame war in 
comp.lang.c.  The characteristic of a high level language is that is has
abstractions -- it isn't raw assembly.  And pointers in C are such an 
abstraction.

>Higher-level constructs are better - _not_ because they are more powerful,
>but because they are less so.  They apply additional semantic constraints
>on how the constructs work which are useful to both the programmer and
>the compiler in producing optimal and correct code.

I don't necessarily disagree.  In fact I just made an argument of this kind
in favor of pointers that have "additional semantic constraints" over and
above "raw addresses".

The question to you now is: Why do you think this kind of abstraction is
wrong and what kind of abstraction -- raw addresses aren't -- is the 
right one?