🚀 go-pugleaf

In article <1990Oct10.193502.2011@d.cs.okstate.edu>, norman@d.cs.okstate.edu (Norman Graham) writes:
> 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.

			.......................

> Pointers are not the only way of providing these kinds of operations--
> they're not even the most beautiful (conceptually speakin, of course).
> The ability to pass functions to function and to store functions in
> data structures only requires that functions be first class values in
> the language: Pointers to functions are unneeded if functions are 
> values in the language. You just need to match the tool to the 
> problem. If you require pointers, use a languages with pointers;
> otherwise use a conceptually more simple language~r{_{_.

There are real simplifications and apparent simplifications.

Suppose that internally information is being passed in a computer.  Now
the only ways that I can see to pass this information is to pass all or
part of the value, the name, or a pointer.  By part, one can pass part of
the value and a way to get at the rest, so that the problem is repeated,
although there are many places where this is done; many string procedures
pass part of the string and pointers to what is before or after.

Now passing the value may be the best way to do things, or passing a pointer.
Passing the name only rarely; interpreters are slow, and compilers and linkers
normally replace names with values or pointers, even for first-class objects.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)