Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <13939@lanl.gov>
Date: 15 Jun 89 22:05:09 GMT
References: <147@unmvax.unm.edu>
Distribution: usa
Organization: Los Alamos National Laboratory
Lines: 30

From article <147@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd):
> In article <13938@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:

>> Of course, if POINTER is supposed to be defined as Walt claims, it isn't
>> really a pointer.  So it's misleading to people who know pointers from
>> other languages.  Furthermore, it needlessly complicates the semantics
>> of pointers when they are used in more conventional roles (recursive
>> data structures, for example).
> 
> I don't follow this.  It simply means it can point to more complex
> objects than in many languages.  I also don't see how it complicates
> things when pointers are used to implement recursive data structures;
> [...]

If you haven't got a complete definition of the semantics of POINTERS,
I don't see how you can verify that the new functionality doesn't contain
non-intuitive 'gotchas' when pointers are used in their more conventional
roles.  As you say, POINTERS can 'point' (actually whole dope vectors are
involved) to more complex objects: which means that this increase in
complexity _can_ take place inadvertently - especially if the pointer
is defined in a MODULE or INCLUDE file and the pointer assignment is
non-local also.  A complete specification of the semantics of POINTERs
would satisfactorily answer this issue.  It _is_ possible to define
semantics _without_ specifying implementation details.

Also, if the new functionality is separable from the old, traditional,
uses of pointers, why does this new functionality share the same syntax?
This violates the principle of orthogonality in language design.  Separate
features should have separate syntax.  So: aliasing array sections should
be _different_ than implementing recursive data structures!