Subject: Re: why we have cons? From: Erik Naggum <clerik@naggum.no> Date: 1998/01/05 Newsgroups: comp.lang.lisp Message-ID: <3093009022019380@naggum.no> * Xah | In the course of discussion, I think there is a concept I'm trying to | express but has been explicitly indicated as stupidity by Eric. well, arrogant ignorance, actually, from which there is both room and hope for improvement, provided one is willing to listen. | In the path of abstraction, it is conceivable a goal to have a | *programming* language that is more or less a concrete embodiment of | algorithm specification, where any references to hardware or | implementation is not existent in the language. I don't think this goal is conceivable, simply because, pragmatically, anything we want to do on a computer has to be implemented somehow, and philosophically, even your most abstract notions are implementations of something else. ergo, implementations are ipso facto unavoidable. | The programmer is only concerned of writing algorithms without needing to | know computer science byproducts like string, float, int, double, OR, | cons. no, a _programmer_ is concerned with strings, floats, ints, doubles, and conses because he is _implementing_ an algorithm on a _computer_. that's what programming is all about. but somehow, it is still permissible for computer scientists to sneer at their tools. Dijkstra has reportedly said that "Computer science is as much about computers as Astronomy is about telescopes", and we can appreciate this in terms of our discipline being much _more_ than just hardware and implementations, but we cannot _deny_ the computer any more than astronomers can deny their telescopes. that a programmer is often tasked with algorithm design is due to a shortage of algorithm designers who are clueful enough to present works that take less time for programmers to implement than to do it all over on their own would, plus the way we work on computers these days, and finally, how computers tend to be hostile to handwaving and explanations that don't take the form of a precise program. | In this ideal language, it would be a kludge to say cons (or pairs) is | necessary to build up a list, or that there are several ways to represent | a tree because of efficiency. Efficiency is an idea in algorithm, but | implementation efficiency is not. e.g. Scheme's (vector 1 2 3) vs (list 1 | 2 3) vs (cons 1 (cons 2 (cons 3 (cons nil)))). what's ideal depends on what your idea is. ideals cannot be universal. however, as I alluded to, Scheme as a language blew it in just the areas where its proponents make the most noise about being superior to every other language. that Scheme forces you to be fully aware of the cons cell through the accessors `car' and `cdr' is just an instance of this. Common Lisp has the constructors `list' and `list*', the accessors `first', `second', ..., `tenth' for individual elements in a known list structure, `nth' and `elt' for a variable index, and `rest' for the tail. a test for the end of a list is available with `endp'. not a `cons', `car', `cdr' or `nil' in sight! of course, you _could_ implement these in Scheme, too. | Mathematica is a language that represents trees uniformly. All trees are | simply List[...]. I came from a Mathematica background, and this is what | prompted me to question on Scheme's cons. _all_ of your complaint is that you can see the internals of the `list' abstraction in Scheme and Lisp that you cannot in Mathematica? right? I think I understand how you argue, and all I can say is that we do have a point of agreement: it's bad design to force programmers to deal with an implementation issue when it costs _nothing_ to do the Right Thing and hide behind names that suggest a more abstract view and communicate to the programmer (who is much more important than the computer) that one deals with lists, not with cons cells, regardless of what the thing actually does (because that's implementation details that you don't want to deal with _needlessly_). I believe that you would never have observed the implementation if you had not _had_ to deal with `car' and `cdr', but you drew the wrong conclusion from the evidence: that an implementation is redundant because you're used to the interface. suppose that things were implemented exactly the same way, but you couldn't get at the individual cons cells. would you still complain? I honestly don't think you would. which leads me to believe that if you had learned Common Lisp instead of Scheme and read source code from the best and most modern CL programmers, you would never have had reason to discover the implementation of lists. if you are still bothered by the fact that a list is made up of conses, that must mean that you _are_ concerned with implementation details, yet you profess very strongly that you aren't, so I detect a contradiction in your interests. if this is not so, may I ask what your real concern is? | It is conceivable that efficiency/abstraction tradeoff are unavoidable in | theory, of designing/implementing a programming language. well, it is not only conceivable, it is obvious to me. | Eric's argument that cons is a *necessary good* as a primitive for list | alludes to me the steoretypical argument between C and lisp programers. | One camp wants control, the other abstraction. if this is really what you got out of it, then you should go back and read my article again, unless you don't think this, anymore. abstractions exist in levels, level N being implemented in level N-1. your only complaint is that you see one more level than you're used to from Mathematica. this isn't even close to _any_ stereotypical argument between Lisp and C programmers. C programmers want easy implementation, frequently at the cost of prohibiting abstraction. Lisp programmers want implementations that _support_ abstraction. as I tried to showed you, the implementation of lists with cons cells is foreign to C programmers, who _much_ prefer fixed-sized vectors of pointers or a "next" pointer _in_ the particular objects they wish to make lists of. a C programmer who had invented the cons cell as a struct or a two-element vector of pointers would probably be laughed at because it's _inefficient_ in the minds of other C programmers. | In Mathematica, there is no cons notion in any form what-so-ever. well, so it would have been redundant in Mathematica. otherwise, they would have implemented it, right? I criticize your claim as arrogantly ignorant because you can not, in fact, hold on to needs that Mathematica solved for its users when you argue that the cons cell is redundant in _Scheme_ as you are flat out _ignoring_ the needs that Scheme (and other Lisps) solved. if they didn't need it, it wouldn't be there. you have to give the language designers this much credit. if not, you are still arrogant and ignorant, like so many others who find flaws with #:Erik -- The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20! Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/