Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!uokmax!d.cs.okstate.edu!norman From: norman@d.cs.okstate.edu (Norman Graham) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: <1990Oct10.193502.2011@d.cs.okstate.edu> Date: 10 Oct 90 19:35:02 GMT References: <2627@l.cc.purdue.edu> Organization: Oklahoma State University Lines: 71 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. > > I must strongly object. When one considers what a variable or any other > type of reference is, it is a pointer. Fortran originally only used > pointers, as there was no call by value. I cannot imagine a language > for mathematical use which does not have variable arrays, functions, > etc. These are all expressed, consciously or not, as pointers. Pointers will always be required by those who demand that languages reveal the machine-level representations of their constructs. But that is only one view that languages can provide: Languages can provide no information about the location of a value, or they can remove the notion of storage (memory) entirely. Are these latter views bad? It depends on the design of the rest of the language. I cannot imagine that 'mathematical use' requires that pointers (or memory for that matter) be part of the language--unless by 'mathematical use' you mean the class of problems that requires very fast massaging of large matricies (i.e. wringing the most computation from every cpu cycle). In this case, efficiency is paramount; assembly language coding is not out of the question here. IMHO, pointers are required only when directly manipulating hardware devices (as in operating systems). > 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. Certainly, if pointers are values in the language then we should make them first class citizens: They must be able to point to any value that is conceptually stored in memory; pointers should be able to be stored in data structures, passed to and from functions, etc. > One has to go through contortions in Fortran to use a subroutine which > has a variable function or subroutine as an argument. 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? 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. 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{_ {_. -- Norman Graham {cbosgd,rutgers}!okstate!norman The opinions expressed herein do not necessarily reflect the views of the state of Oklahoma, Oklahoma State University, OSU's Department of Computer Science, or of the writer himself.