From ...
From: Erik Naggum
Subject: Re: why we have cons?
Date: 1998/01/05
Message-ID: <3093009022019380@naggum.no>
X-Deja-AN: 313000932
References: <3092837184154309@naggum.no>
mail-copies-to: never
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Newsgroups: comp.lang.lisp
* 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/