Path: utzoo!attcan!uunet!snorkelwacker!usc!wuarchive!cs.utexas.edu!yale!cmcl2!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: <65409@lanl.gov> Date: 10 Oct 90 21:57:17 GMT References: <2627@l.cc.purdue.edu> Organization: Los Alamos Natl Lab, Los Alamos, N.M. Lines: 129 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