kend@data.UUCP (Ken Dickey) (10/26/90)
peter@ficc.ferranti.com (Peter da Silva) writes: >First of all... what's a pointer? It's not a machine address. A pointer is >a token that refers to a value, such that it can refer to any value in >the domain of the language, and that more than one such token can refer >to a given value. The operation of getting to the value referred to is >called dereferencing. Where are you getting your definition of pointer? Not from K & R: "The C Programming Language. Not from Ullman: "Fundamental Concepts of Programming Systems". Not from Trembly & Sorenson "An Introduction to Data Structures with Applications". Et cetera... Have you ever heard the phrase "pointer arithmetic"? >In article <418@data.UUCP> kend@data.UUCP (Ken Dickey) writes: >> Gee, I thought there was this constructor CONS which takes two values. >And returns a pair of pointers. It can be implemented by writing down on >a piece of paper the safe-deposit-box-numbers of a safe-deposit-box in >New York City, but it is still functionally a pair of pointers. (cons 3 3) returns an *object* with 2 *values* and NO pointers! >> It is true that there are pointers all through typical implementatons >> of Scheme, but there is no "pointer" in the definition of the language! >This is only a true statement if you think "machine address" when I say >"pointer". Thats right! I think "store location" when you say "pointer"! You will ceratinly find no mention of "pointer" in the Scheme language. -Ken Dickey kend@data.uucp
kend@data.UUCP (Ken Dickey) (10/30/90)
peter@ficc.ferranti.com (Peter da Silva) writes: >Not all languages with pointers allow arithmetic on them. And you never >need to do arithmetic on a pointer in C... it is merely convenient. This >has nothing to do with the definition of a pointer. The definition of "pointer" comes from an extensive body of literature on computation. You should use a term with a meaning closer to what you wish to express rather than redefining a term with an established meaning. CS is already full of overdefined terms. >> By "token" (a syntax concept), I presume you mean "identifier" (a >> language concept). >No, I mean a token. An opaque object. The term is used in other contexts >than compiler design... consider its use in networking. The rest of your >paragraph is complete gibberish, I'm afraid, because it's based on a >misconception. In the context of computer programming languages, "token" has a meaning in the context of syntax. I did not know you were speaking of networks. What is the meaning of "pointer" in the context of network? >What you're arguing about here isn't whether one should have pointers >at all, merely how restricted the operations on pointers should be. And >that's a horse of a different color. I am arguing whether "pointers" are available as a source language concept. If I have a "house", it is defined in terms of roof, walls, etc. I speak of being in a particular room, etc. A house may be (but does not have to be) constructed partially from "boards". I do not talk about going from room to room in a house by speaking about boards. Boards are not a "house-level" concept. Why do you insist on redefining board to be a unit of room traversal? >I use C for pragmatic reasons. It's the only language that's powerful >enough for most of the stuff I do that's also widely available and has >a good enough standard library. I use Scheme for pragmatic reasons. It gets in my way the least of any language around and--unlike C--is portable to a wide variety of machines with the use of a small source file which encapsulates implementation differences. [I routinely work on Vax, Sun3/4, Amiga, PC, Mac, etc. with the same Scheme source]. C lacks good encapsulation facilities. I don't want to worry about the size of an int! It lacks closures. It is *not* powerful enough for many things that I do. I do use it for device drivers and bootstraps, but C is too fragile for reasonably sized software systems. > You just can't *get* good Pascal, Modula, >Smalltalk, what-have-you implementations on most of the machines I have >to work with. I'm not going to claim it's even a very good langauge. But >it's there, and works, everywhere I need it to be. You want to help improve >things... write some compilers and sell them cheaply. I have just started a port of Brandeis' Gambit Scheme Compiler to the Amiga. Will this help? [Seriously, let's take the language bashing off-line] -Ken kend@data.uucp
peter@ficc.ferranti.com (Peter da Silva) (10/31/90)
In article <422@data.UUCP> kend@data.UUCP (Ken Dickey) writes: > The definition of "pointer" comes from an extensive body of literature > on computation. You should use a term with a meaning closer to what > you wish to express rather than redefining a term with an established > meaning. CS is already full of overdefined terms. Fine. You want to play name games. THe question at hand is "what is a pointer", or "what is it that makes pointers dangerous". To answer this question you have to ask "what is a pointer" in terms of what we want to know about them. If you think the fact that a pointer points at a machine address (an implementation detail) is significant, then is Sabre-C a pointerless language? If so, what is significantly different between it and conventional C implementations? > In the context of computer programming languages, "token" has a > meaning in the context of syntax. I did not know you were speaking of > networks. What is the meaning of "pointer" in the context of network? No, the term "token" has a meaning in the larger world of CS: a token is an opaque object that refers to another object. In the context of compilers it's a small easily-handled object that refers to a string of characters. In the context of a network it's a logical object that's passed between machines on the network to indicate which machine has the right to pass a message on. (in the context of a network, I guess "xds13.ferranti.com" is a pointer) > I am arguing whether "pointers" are available as a source language > concept. So am I. Warning... skip the next few exchanges if quibbles about irrelevent analogies bore you. > If I have a "house", it is defined in terms of roof, walls, > etc. I speak of being in a particular room, etc. A house may be (but > does not have to be) constructed partially from "boards". I do not > talk about going from room to room in a house by speaking about > boards. Fine, but for some reason you're denying that an apartment is a house because it doesn't have 4 walls of its own. > Boards are not a "house-level" concept. Why do you insist on > redefining board to be a unit of room traversal? You're completely misinterpreting me if you think that. I don't care what the underlying implementation does. It doesn't have to have machine addresses in the implementation anywhere... look at the UNIX file system: a link (either symbolic or hard) is a pointer, but there are no CPU addresses involved at all. Hell, a symbolic link can point into another address space! > [Seriously, let's take the language bashing off-line] Huh? Who's language-bashing? -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
jlg@lanl.gov (Jim Giles) (11/01/90)
From article <35S67X@xds13.ferranti.com>, by peter@ficc.ferranti.com (Peter da Silva): > In article <422@data.UUCP> kend@data.UUCP (Ken Dickey) writes: > [...] >> [Seriously, let's take the language bashing off-line] > > Huh? Who's language-bashing? Besides, what's wrong with language bashing? This _IS_ comp.lang.misc after all. It seems to me that the only purpose of this newsgroup is to discuss new languages, availablility of language processors, and language features (good and bad). If this results in bashing certain languages with more than their fair share of 'bad' language features - that's just part of the correct function of this newsgroup. In fact, how is it possible to discuss the relative merits of different languages without 'bashing' some of them (at least in part)? J. Giles