Subject: Re: What are parentheses for? (was Lisp/Scheme with less parentheses ...)
From: Erik Naggum <erik@naggum.net>
Date: 2000/08/16
Newsgroups: comp.lang.lisp
Message-ID: <3175408485778175@naggum.net>

* bayinnaung@my-deja.com
| all lisp languages are based on the lambda calculus

  Lambda calculus is a means of reasoning about computation.  It is
  universal, like mathematics, not limited to any particular languages.

| Why cons cells,

  Why are you concerned about them?  They're an implementation of
  lists, which is a way to describe nested structure neatly.  In
  principle, any other implementation would be just as useful, even
  something as uselessly complex like DOM used with XML, but that
  serves no purpose at all.

| Why s-expressions?

  You're looking for the history of Lisp.  But note that atoms, like
  symbols, numbers, vectors, etc, are symbolic expressions.

| Are there straightforward ways to think about the mapping between
| them?

  Huh?

| For instance if you have trees represented one way by lists/
| s-expressions and you want to transform these trees to another tree
| format?

  It's extremely unclear what you really are asking for.  Of course
  it's trivial to express a tree any other way, but that is not a
  transformation, and transformations aren't related to formats of
  representation.

| Lisp-lists/cons-cell-structures sure do allocate a lot of storage

  Oh, really?  Well, this statement marks you as clueless and arrogant
  enough to post unfounded statements without any shame.  What are you
  _really_ after?

  Any list structure (that is, not vectors), will have to consist of
  at least one pointer per element, called "next".  If you should be
  able to make lists of all kinds of objects, you can either have a
  "next" element in all kinds of objects (or arrange for different
  kinds of objects in the free and in lists, which is even dumber) or
  you can have a cons cell which consists of two pointers, one to the
  object, one to the next element.  Since most naive programmers who
  implement lists think they need doubly-linked lists, which they
  don't except in very rare cases, you don't waste any space at all.

  It is regrettable that Lisp systems let users see allocation data
  when they are so amazingly clueless as to be unable to understand
  the choice of models involved and what the information means and
  doesn't mean.

| but you don't seem to be able to do much with them.

  *laugh*

| Can you index into big cons trees and change values or insert cons
| cells (cons cell surgery)  (set-cdr in scheme can do this),

  Yes.  (Obviously.)

| there seems to be a real limit to what you can do destructively in
| lisp

  Why do you flaunt your ignorance so shamelessly?  Just flame bait?
  Aren't you even aware that programmers have been using Lisp for over
  40 years?  Do you believe that you're the only non-idiot to have
  picked up Lisp?

  People don't use destructive operations as much in Lisp because they
  have better ways of doing what is normally done destructively, and
  they don't want to get into object ownership protocols, but when you
  have to, everything you need is there.  Of course.

| you can destructively push onto the front of a list, but you
| have to write your own macro if you want to push onto the end
| (compare push shift in Perl)

  Oh, geez, it's a Perl-head.  What do you think the "macro" does if
  you can't already do it in the language?  Sheesh.  If you really
  have to, do:

(setf (cdr (last <list>)) (list <whatever>))

| These are questions/observations I have from experimenting with Lisp.

  Really?  What do you think happens if you "experiment" with a hammer
  and a bunch of nails?  Do you get a useful grasp of the art and
  craft of carpentry, even an inkling of what is involved?  After
  pounding a dozen nails into your living room table, do you exclaim
  "you can't possibly build anything with this!"?

| Any answers would be appreciated.

  It will require concentration and effort, but try a textbook.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.