> From: Xah Lee <x...@[EMAIL PROTECTED]
>
> The cons business. (lists are made up of cons cells and it is
> necessary for the programer to understand this to write any non-
> trivial lisp program)
IMO the way to write a program is to design an abstract data type
then to use it. Only the person hand-coding the implementation of
that ADT need worry about low-level details such as cons cells.
Most of the time the programmer can use mapping functions (for
lists, or for association lists, or for property lists, or for hash
tables, or for various binary trees such as AVL trees) and not
really care that these various structures are really built of cons
cells. But the fact that structures (except hash tables and arrays)
are directly built out of cons cells allows different objects to
share common structure. For example, large binary trees can share
all but the changes, thereby allowing update of a tree
non-destructively to take log(n) time, keeping both old and new
around simultaneously taking only log(n) extra space beyond a
single copy.
> No highlevel treatment of lists. (In Mathematica, there are a
> system of functions to extract or manipulate (nested) lists
> considered as trees. e.g. getting all elements at a level, or
> arbitrary set of nodes of a tree. All these based on a tree index
> concept. (i.e. first branch's second branch's third's branch will
> be 1,2,3.) In lisp, programers uses cons, car, cdr, caadr, etc.
Why 1,2,3 instead of 0,1,2? That point is too petty to fuss over.
Otherwise, you're just plain wrong. Look up the fuction NTH,
which indexes down a list by a given number.
Then imagine how trivial it is to write a function that uses a list
of successive indexes to specify the element number at successive
levels within a list, calling NTH at each level.
You can even offset by one if you really really need that.
|
