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/