kend@data.UUCP (Ken Dickey) (11/01/90)
You should probably hit `N' here... -Ken peter@ficc.ferranti.com (Peter da Silva) writes: >In article <422@data.UUCP> kend@data.UUCP (Ken Dickey) writes: ken>> The definition of "pointer" comes from an extensive body of literature ken>> on computation. You should use a term with a meaning closer to what ken>> you wish to express rather than redefining a term with an established ken>> meaning. CS is already full of overdefined terms. peter>Fine. You want to play name games. THe question at hand is "what is a peter>pointer", or "what is it that makes pointers dangerous". To answer this peter>question you have to ask "what is a pointer" in terms of what we want peter>to know about them. What is wrong with using the standard definition of pointer? I have given a number of references which support my interpretation. I think that it is you who are playing word games by redefining things as you go along. peter>If you think the fact that a pointer points at a peter>machine address (an implementation detail) is significant, then is Sabre-C peter>a pointerless language? If so, what is significantly different between peter>it and conventional C implementations? I know of no programming language called "Sabre-C". You are confusing language with implementation here. ken>> In the context of computer programming languages, "token" has a ken>> meaning in the context of syntax. I did not know you were speaking of ken>> networks. peter>No, the term "token" has a meaning in the larger world of CS: a token is peter>an opaque object that refers to another object. In the context of compilers peter>it's a small easily-handled object that refers to a string of characters. In the context of compilers, a "token" is a (meaningless) unit of syntax. Meanings come into play in the semantics which results from the analysis. I have looked through a number of standard CS texts and have been unable to find a definition of "token" other than an a meaningless (but unique) marker used in token-ring networks or as a syntactic unit in computer language analysis. I ask again, what are the references which support your definition? peter>.. I don't care what peter>the underlying implementation does. It doesn't have to have machine peter>addresses in the implementation anywhere... look at the UNIX file system: peter>a link (either symbolic or hard) is a pointer, but there are no CPU peter>addresses involved at all. Hell, a symbolic link can point into another peter>address space! So where has someone defined pointer == link? Go back and look up "pointer" in a few standard textbooks. -Ken
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (11/01/90)
In article <423@data.UUCP>, kend@data.UUCP (Ken Dickey) writes: > peter>No, the term "token" has a meaning in the larger world of CS: a token is > peter>an opaque object that refers to another object. In the context of compilers > peter>it's a small easily-handled object that refers to a string of characters. "peter" is right. > I have looked through a number of standard CS texts and > have been unable to find a definition of "token" other than an a > meaningless (but unique) marker used in token-ring networks or as a > syntactic unit in computer language analysis. I ask again, what are > the references which support your definition? You could start by looking in almost any book on dataflow machines. You could look at Allen, "Natural Language Understanding", where we find "A new class of nodes [in a semantic network], called TOKENS, is introduced to represent particular objects and particular actions". This is almost exactly the sense in which "peter" used the word. Then there are place/transition nets. A few more textbooks may be in order. -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.
peter@ficc.ferranti.com (Peter da Silva) (11/02/90)
In article <423@data.UUCP> kend@data.UUCP (Ken Dickey) writes: > What is wrong with using the standard definition of pointer? Because it's not useful in this context. > I have given a number of references which support my interpretation. With all due respect, that is just another version of a dictionary flame. > I think that it is you who are playing word games by redefining things > as you go along. And I'm still using the same definition of a pointer that I was using when I jumped in: a token (AKA opaque object AKA explicit reference) that refers to an atomic value (AKA object AKA atom AKA primitive). I'm just trying to find words to fit into those slots that don't blow your fuses. Why don't you put the words that make your head feel happy in so we can go on? > I know of no programming language called "Sabre-C". You are confusing > language with implementation here. No, I'm pointing out that the C pointer model can be implemented without the pointers being machine addresses. So "pointer==machine address" is not a useful definition for a discussion of languages. > In the context of compilers, a "token" is a (meaningless) unit of > syntax. Fine. I'm not talking about compilers. The rest of your article is more dictionary flames. If you want to do that then hit the 'r' key. If you want to go back to an operational definition of a pointer so we can discuss what a pointerless language might be then hit the 'f' key. If you really don't see what I'm getting at hit the 'n' key. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
gl8f@astsun8.astro.Virginia.EDU (Greg Lindahl) (11/02/90)
In article <423@data.UUCP> kend@data.UUCP (Ken Dickey) writes: >What is wrong with using the standard definition of pointer? Pointers are implemented in languages in ways that are easy or hard to optimize. If you think there's one definition that fits all pointer implementations, then it's a definition which is totally useless to someone talking about optimization. A definition that tells you a lot about optimization might not tell you much about other properties. And so on. Just because a textbook gives an overly-general answer to a subtle question doesn't mean that's the correct answer.