🚀 go-pugleaf

From article <2627@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin):
> In article <2883@igloo.scum.com>, nevin@igloo.scum.com (Nevin Liber) writes:
>> In article <64618@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>  
>> >It is my contention that future languages
>> >shouldn't have pointers at all.  Not just no C-like pointers, none at
>> >all.  I just picked on C as the most unpleasant example of what I'm
>> >against.
>  
>> I really hate to agree with you Jim :-), but I'm beginning to think
>> that you are right.  The only real argument I can see _for_ having
>> pointers is efficiency; more specifically, to help in
>> hand-optimisation.  Extensions to C such as C++ are showing that
>> pointers aren't needed nearly as much as they use to be; heck, code
>> seems to be more readable w/o them.  In languages such as Icon and
>> LISP I find that I don't even miss them.

This discussion was cross-posted without adequate context to allow
clear discussion.  The assertion I made above was with respect to
_explicit_ pointers - most of the functionality of which is possible
in clearer ways.  For example, one dimensional arrays are semantically
equivalent to bounded pointer domains (with the subscript acting as
the pointer) - however, since the arrays are bounded, it is possible
to make assertions about aliasing between references that unbounded
pointers don't allow (different arrays are disjoint, for example).

> [...]
> I must strongly object.  When one considers what a variable or any other
> type of reference is, it is a pointer.  [...]

Almost.  Variables (and most constants) in procedural languages are
_usually_ (but not always) allocated some specific memory location
(either dynamically or statically) in which to keep the value of the
symbol.  The address of this memory location is an attribute of the
variable (like its size or type - which are also attributes).

A pointer, on the other hand, is a variable whose _value_ is an
address.  It also _usually_ has an address part as an attribute -
which points to the address which is the value.  But, addresses
aren't particularly important to me.  I almost never need to know
or manipulate them in any way.  So, why do I need a data type who's
values are addresses?

> [...]                                   Fortran originally only used
> pointers, as there was no call by value.  [...]

Fortran did no such thing.  Fortran has _always_ been designed to allow
_either_ call by reference _or_ call by value/result.  On many machines,
particularly the new massively parallel machines like the Connection
Machine, call by value/result is _much_ more efficient.  It's cheaper
to copy the data in and out than to have the procedure always reading
across the network of CPUs for it.

> [...]                                    I cannot imagine a language
> for mathematical use which does not have variable arrays,

Neither can I.  But these don't need explicit pointers.  Nor, do they
even, necessarily, need call by reference as I pointed out above.

> [...]                                                functions,
> etc.

Yes, I think that languages should have these too.  But, it's clear to
me that pointers are not the proper way.

> [...]  These are all expressed, consciously or not, as pointers.

Not necessarily.

> [...]
> Now if one can have fixed pointers, why not variable pointers?  We are
> no longer in the days when the only way to call a subroutine was to
> have the address in the instruction.

Why not leave pointers out of it and provide explicit ways of altering
the reference attribute of a variable in specific ways?  We are no longer
in the days when anyone _cared_ about the absolute addresses of anything.
Why have a data type which purports to represent them?

> [...]
> One has to go through contortions in Fortran to use a subroutine which
> has a variable function or subroutine as an argument.  [...]

Yes, and the solution to this problem is to have a data type called
'function', and allowing variables of that type to be declared.  For
example, suppose you have a random number generator called ranf() which
has an optional argument allowing you to set the seed.  Why shouldn't
the language of the future allow this:

   Function (optional float) -> float :: x, y      !declare x, y the same
						   !type as ranf()

   x = ranf                !not an evaluation - an assignment to x
   y = ranf                !ditto for y

   dummy = x(some_seed)         !set seed for x
   dummy = y(some_other_seed)   !set seed for y

Now, you have two independent generators with different seeds that
both are "copies" of the ranf() code.  Actually, the only part the
implementation needs to copy is the internal static variables of
the routine - all else can use the same code.

> [...]                                                 Now there are
> developments in programming languages which should have been apparent
> way back when which may decrease the need for some uses of pointers,
> but why hobble the intelligent programmer? [...]

Why indeed?  Why force the programmer to use explicit pointers when
the language can be designed to allow the programmer to explicitly
state what he really wants to do?  It's easier for the programmer,
easier for the compiler to generate efficient code, easier all
around.

> [...]                                     I have deliberately used
> arrays of pointers as the most convenient means of handling array
> refill procedures, and while I can find a way around it, it is clumsy
> and even less portable.

Exactly!  Pointers _are_ clumbsy and less than portable.  What you
really wanted was probably an array of sequences, or an array of
functions, or an array of dynamic arrays (not the same as a 2-d array -
in an array of arrays, each element of the parent array may have a
different size or even a different allocation status from its
siblings).  If the high-level language gave you those concepts, you
wouldn't need explicit pointers and you would get portability (where
ever the language was).

J. Giles