kend@data.UUCP (Ken Dickey) (10/18/90)
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >(Since Lisp has rplaca/rplacd -- or, in Scheme, set-car!/set-cdr! -- Lisp >is a very poor example of a "pointerless: language...) I fear I have missed most of the discussion (our news feed is not the most robust), so my comments may be somewhat random, but here goes... There are a number of programming languages, Scheme and ML among them, which do not have a pointer abstraction. This is not to say that pointers are not used in their implementations. Typically, such languages concentrate on values. Whether a value is small enough to fit in a register is the concern of the implementation. Such languages support rapid, reliable code development by eliding a whole class of user errors. [After programming in Scheme for a few days, no one ever "falls off the end of a pointer chain" or "defererences a bogus pointer"]. Such languages tend to be more abstract and hence more portable across machine/os architectures than languages like C. Sure, there are people who prefer to write device drivers, etc. in C. But trying to scale up a device driver level development technology is an expensive and error prone way to build software systems. -Ken Dickey kend@data.uucp
kend@data.UUCP (Ken Dickey) (10/18/90)
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes: >(Since Lisp has rplaca/rplacd -- or, in Scheme, set-car!/set-cdr! -- Lisp >is a very poor example of a "pointerless: language...) I fear I have missed most of the discussion (our news feed is not the most robust), so my comments may be somewhat random, but here goes... There are a number of programming languages, Scheme and ML among them, which do not have a pointer abstraction. This is not to say that pointers are not used in their implementations. Typically, such languages concentrate on values. Whether or not a value is small enough to fit in a register is the concern of the implementation. Such languages support rapid, reliable code development by eliding a whole class of user errors. [After programming in Scheme for a few days, no one ever "falls off the end of a pointer chain" or "defererences a bogus pointer"]. Such languages tend to be more abstract and hence more portable across machine/os architectures than languages like C. Sure, there are people who prefer to write device drivers, etc. in C. But trying to scale up a device driver level development technology is an expensive and error prone way to build software systems. -Ken Dickey kend@data.uucp
peter@ficc.ferranti.com (Peter da Silva) (10/19/90)
In article <415@data.UUCP> kend@data.UUCP (Ken Dickey) writes: > There are a number of programming languages, Scheme and ML among them, > which do not have a pointer abstraction. The *only* abstractions in scheme are a pair of pointers or a value. > [After programming in Scheme for a few days, no > one ever "falls off the end of a pointer chain" or "defererences a > bogus pointer"]. Sure. If you've got data in a list, say: ("da Silva" "Peter" "ferranti.com" "peter") And you accidentally return (cdr list) instead of list, you have all the problems as you do in C when you return a pointer to the middle of the array. Oh, sure, the *symptoms* are different, but when you have an object (a C pointer, or a dotted pair) that can point to any arbitrary place in any non-atomic language object (a string, or a list) you have the exact same problem. This is not to say that scheme doesn't make the consequences of falling off a list or taking the cdr of a bogus pair less dire, but claiming that languages like scheme "don't have a pointer abstraction" is going a bit far. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jpiitulainen@cc.helsinki.fi (10/20/90)
In article <+CI6:YD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > In article <415@data.UUCP> kend@data.UUCP (Ken Dickey) writes: >> There are a number of programming languages, Scheme and ML among them, >> which do not have a pointer abstraction. > > The *only* abstractions in scheme are a pair of pointers or a value. It is a pair of values. Pointers to values, as separate from values, do not exist. Pointers (addresses) are usually used in the implementation, because pairs are required to retain their unique identities when they are stored in data structures: the same pair (or vector, or character, or string, ...) can be stored in several data structures at the same time. In C you use pointers for this, and it is a different thing to store an int in a record, or to store a pointer to an int there. In Scheme, any pair or vector can hold arbitrarily big values---even itself---pointers are not needed and there is no such thing as a pointer to an integer. I find the difference as real as Ken Dickey evidently does. (Also, I find your emphasis on "only" very strange. At least, if pairs are abstractions, then vectors and strings should be, too. Procedure formation has long been called "abstraction" in Scheme community, and Scheme is really more about lambda than about data structures. Is this a different use of the word?) > ... > And you accidentally return (cdr list) instead of list, you have all the > problems as you do in C when you return a pointer to the middle of the > array. Oh, sure, the *symptoms* are different, but when you have an > object (a C pointer, or a dotted pair) that can point to any arbitrary > place in any non-atomic language object (a string, or a list) you have the > exact same problem. The same problems are there, when applicable. Lists are just chains of pairs, or pairs who's cdr fields are pairs, and the cdr pair can be a part of some other list, too. Thus mutation is dangerous. You can't have a "pointer" to the middle of a vector or a string, though. A value in the middle of a vector can have many names, but it will not provide access to any other vector element. > Peter da Silva. `-_-' > +1 713 274 5180. 'U` > peter@ferranti.com Jussi Piitulainen jpiitulainen@hylka.helsinki.fi
peter@ficc.ferranti.com (Peter da Silva) (10/24/90)
In article <3407.2720318d@cc.helsinki.fi> jpiitulainen@cc.helsinki.fi writes: > In article <+CI6:YD@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter > da Silva) writes: > > In article <415@data.UUCP> kend@data.UUCP (Ken Dickey) writes: > >> There are a number of programming languages, Scheme and ML among them, > >> which do not have a pointer abstraction. > > The *only* abstractions in scheme are a pair of pointers or a value. > It is a pair of values. Pointers to values, as separate from values, do > not exist. So, (a) is the same as a? > Pointers (addresses) are usually used in the implementation, No, addresses are not what I mean by pointers. The definition of a pointer that I am using is "a token that can refer to any language object". The operative word is "any". > In Scheme, any > pair or vector can hold arbitrarily big values---even itself---pointers > are not needed and there is no such thing as a pointer to an integer. Really? As far as aliasing and debugging are concerned (3) is a pointer to 3. (well, to 3 and nil) > The same problems are there, when applicable. Lists are just chains of > pairs, or pairs who's cdr fields are pairs, and the cdr pair can be a > part of some other list, too. Thus mutation is dangerous. *Exactly*, just as arbitrary pointer operations are dangerous. And for exactly the same reasons. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jpiitulainen@cc.helsinki.fi (10/27/90)
In article <XFM6-F1@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: > In article <3407.2720318d@cc.helsinki.fi> jpiitulainen@cc.helsinki.fi writes: > >> It is a pair of values. Pointers to values, as separate from values, do >> not exist. > > So, (a) is the same as a? One is a list containing the other. > No, addresses are not what I mean by pointers. The definition of a pointer > that I am using is "a token that can refer to any language object". The > operative word is "any". Is a pair a "token that refers" or does it contain two of those? If you define "pointer" so that pairs, vectors, variables and procedures and everything built of them become "pointers", then of course Scheme has pointers, but what's the point? Also, in that case the word is no longer useful to describe C pointers. >> are not needed and there is no such thing as a pointer to an integer. > > Really? As far as aliasing and debugging are concerned (3) is a pointer > to 3. (well, to 3 and nil) There are three things: a pair (3 . ()), an integer 3 and the empty list. The first contains the other two. Whenever P is a pair, there are three things: P itself, the thing that is its head and the thing that is its tail. Any two of them can be the same, or have the other as a component. In that case, they are said to "share structure", or to "be aliased" if you prefer. All the problems of aliasing and debugging that you can have in Scheme can be stated in terms of "identity of things" and "mutation of shared structure", without any "token that refers" that is not one of the language level things involved. There is no such thing as a pointer in Scheme, and no conceptual need for one. Pointers are objects in some languages. In Scheme they are not, and seeing them nevertheless just complicates things. > Peter da Silva. `-_-' Jussi Piitulainen jpiitulainen@cc.helsinki.fi
peter@ficc.ferranti.com (Peter da Silva) (10/28/90)
In article <3702.27287cf3@cc.helsinki.fi>, jpiitulainen@cc.helsinki.fi writes: > Is a pair a "token that refers" or does it contain two of those? If you > define "pointer" so that pairs, vectors, variables and procedures and > everything built of them become "pointers", then of course Scheme has > pointers, but what's the point? Also, in that case the word is no > longer useful to describe C pointers. Sure it is. I'm defining a pointer in terms of an object and operations on that object. A functional definition of a pointer, including all the dangerous (re: pointer as the GOTO of the '90s) aspects of this object. If something looks like a duck, and quacks like a duck, you're welcome to call it an aquatic waterfowl but it'll taste the same. Now if you want to discuss whether the names "Duck", "Aquatic Waterfowl", or even "Mallard" or "Pekin" are more useful... go right ahead. I'll just get back to cooking. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com