Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!tom@nw.stl.stc.co.uk From: tom@nw.stl.stc.co.uk (Tom Thomson) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: <3673@stl.stc.co.uk> Date: 1 Nov 90 15:38:01 GMT References: <2062@aber-cs.UUCP> <1990Oct26.155937.29185@maths.nott.ac.uk> Sender: news@stl.stc.co.uk Reply-To: "Tom Thomson" Lines: 70 I cannot understand why Jim Giles wants pointers to have values which are addresses. The important thing about a pointer is simply that it identifies (unambiguously) the thing to which it refers. The only operations on a pointer are the (a) getting the thing to which it refers; (b) modifying the value of the thing to which it refers; (c) checking whether two pointers refer to the same thing. There is of course no operation that makes the pointer point to something else (that's an operation on a pointer-valued variable which assigns a new pointer to it; think of an integer-valued variable - - if x has the value 3, and the assignment x:=4 is executed, this does not assign the value 4 to the integer 3; pointers are no different from integers in this respect - - and yes, I have come across the broken Fortran compilers that allow you to assign a new value to an integer constant :-) ). There is no earthly reason why a pointer should support any of the extra operations Jim says it has to support (eg ordering), and certainly no reason why an implementation should be constrained to implement it as an address. I wonder if all OO languages implement references to an object as addresses? After all, a reference to an object is no more or less than a pointer to it. Do SQL systems implement all identifiers (keys which are constrained to be unique) as addresses? Well, I suppose that depends on what you mean by an address - - if you regard tables as being content-addressed they do! (PierCarlo seems to advocate that all identification of objects should be by content - - fair enough at some level of description, but it's nice to have syntax which allows us to distunguish a part of the content which can be used to identify the object and call that part a pointer and have nice syntax for using it as the access route to the object; and he appears to object to that). Jim's arrays and indices down them are all very well, but they certainly do not solve the aliasing issue he claims they solve; if I write a[i] := a[j] the compiler does not in general know whether i and j have different values, ie whether i and j are distinct. Once you start using an array of cells to implement a graph structure, with indices used as pointers, you have exactly as much information about aliasing as if you used pointers instead of indices - no more, and no less; however you as the programmer now have the problem of assigning the cells positions in the array, doing your own garbage-collection as cells become free, coping with types whose values don't all occupy the same amount of store (so a cell may occupy multiple slots in the array) and so on; to get the language system to hide all that from you and do it automatically, you need pointers. It's easy to see, of course, that all Jim's arrays do is classify pointers according to whether they $d that all Jim's arrays do is partition the store into a set of non-overlapping regions - so a pointer written a[i] is known to be distinct from a pointer written b[i]; but there is no difficulty at all in partitioning the store and then constraining pointer-valued variables to point into one partition or another: so if p1 is a pointer constrained to point into region r1 and p2 is a pointer constrained to point into region r2 the compiler knows that p1 and p2 are not aliases of each other. There may be a case for low-level languages to have a pointer construct which is constrained to be mapped as an address; for most programming purposes, I would prefer to work in a high level language. I claim that any high level language (other than a single assignment language) must have a pointer concept (although it may call it something else, and may use search on content as the pointer resolution mechanism) since otherwise it cannot express referential sharing and identity - - and if I have mutable objects (ie not a single assignment language) then I must be able to determine which refers to which so that I control whose references are mopdified by an update (incidentally, the implementation may use accidental sharing to optimise storage usage, and move one of the obkjects sharing store when it changes but the other objects sharing that store don't. If the implementation of pointer were address, as Jim insists, the representation of the pointer to that object - and all copies of that representation - would have to change even though the pointer has not changed, it still references the same object. so implementations which use accidental sharing all violate Jim's definition of pointer.) Tom Thomson [tom@nw.stl.stc.co.uk