> From: Xah Lee <x...@[EMAIL PROTECTED]
>
> Let's keep this message focused on just the cons of lisp. ...
> It is surprisingly hard for me to explain how lisp cons is a
> problem to lispers.
I don't believe it *is* a problem. It's hard to explain what ain't so.
> Lisp's List Problem
> http://xahlee.org/emacs/lisp_list_problem.html
> lisp's ways of list is historical and drags in the implementation
details.
No. It makes those details *available* for any application
programmer wi****ng to take advantage of that info. Anyone who
wishes may simply ignore those details.
In fact the *real* implementation details, i.e. how a single cell
of a linked list is constructed at the machine level, is *not*
specified, and application programmers don't need nor use that
secret implementation-dependent info.
> in today's high-level languages, one do not deal with memory
> allocation, linked list, types, etc ...
False. Some algorithms are appropriate for linked lists but not for
arrays, such as any that perform lots of pu****ng/popping at the
start of the list, while other algorithms are appropriate for
arrays but not for liked lists, such as any that do lots of random
access within the list. If the application programmer has no way
(in some particular programming language) to choose between the two
forms of a list, and can't even *know* which is provided by
default, then coding *any* of such algorithms is not worth even
trying, and that programming language sucks IMO.
Java provides java.util.AbstractSequentialList (like a linked list)
specialized to java.util.LinkedList (in fact a doubly-linked list),
and java.util.ArrayList (like an array). Do you consider Java to be
one of today's high-level languages?
> For example, in Python, a list is like this [a,b,c,...] and if one
> wants arbitrarily nested list (such as a matrix, tree, associative
> list, hash, dictionary, key'd-list, vector, array, map, sequence
> ...however one wants to call them), the programer simply write
> [a,b,c,...] where each of the a,b,c can be another list of the form
> [...]. Similarly in Javascript.
How is that any different (except nitpicking details of syntax) in
Lisp? In lisp you use parens instead of brackets, and you don't
need to reach for the comma key, you just bump the space bar which
is easier/faster.
> a programer cannot program in lisp in a real world situation without
> having a good understanding of the cons.
In the other languages, a programmer can't write any code at all
that deals with lists, because the programmer has no idea whether
they are linked lists or arrays, hence can't code for either
assumption.
In Lisp, a programmer can deal with linked lists for appropriate
applications, and with arrays for other appropriate applications.
In Java, a programmer can likewise deal with java.util.LinkedList
or java.util.ArrayList. In the languages you cite, a programmer is
stuck with no choice available and no way to know what's given
hence no way to have the info needed to know how to write the
application.
> the reason for high-level lang being what they are is from all these
> little details.
Wrong. The reason for a high-level language is to offer the
programmer a choice of various common data types (arrays, linked
lists, hash tables, etc.), but hide the details of tag bits and
word size and other details of pointers within these "collections"
(Java jargon).
> a vector or array is simply a list with unchanging length
No. It's that plus the fact that it's laid out in consecutive RAM
so that it can take advantage of Random Accessing by index to
achieve guaranteed constat time index->value.
> A hash is simply a list of element where each element is a list
> of 2 items, and further with the property that one have a
> function that quickly determines whether a key exist etc. (i.e.
> so-called constant time access).
Why does it have to be a list at all?? Why can't it *only* provide
the usually-constant-time key->value function, and not provide
sequential access at all?
> A set is just a list that does not have identical elements.
It must somehow enforce that, unless only constant sets (defined at
compile time and *never* changed at runtime) are sup****ted.
In math, all sets are constants. You can't add elements to a set
and have the *original* set now contain the additional elements.
What you said may be a valid definition of a mathematical set, but
it's not very useful for programming.
You've also begged the question whether the word "list" in this
context means an array or a linked-list.
> A matrix is just a list with element where all elements are lists
> of the same length.
Same length as what? Answer: Same length as each other, but *not*
necessarily same length as the top-level list.
> A tree is simply a arbitrarily nested list... and so on.
OK. But same question as for sets, do you mean array or linked-list?
> But, one may ask, so if one wants a hash-table in Mathematica (or
> other high-level lang) that just have a list, how can one do it? For
> example, its a list of pairs like this {{k1,v1},{k2,v2},...} but how
> can i know that it'll have constant access time when i use the
> language's function to gets the elements of a list? Does it mean the
> programer has to implement it himself? The answer is that the compiler
> should automatically figure out and decide this transparently.
There's no way the compiler can figure out the runtime statistics
of traversing a collection, specifically figuring out whether
access is dominated by sequential access or random access, whether
updates are dominated by ins/del at start, ins/del at end, or
ins/del at random places in the middle. That's the job of the
programmer to declare the intent, such as by choosing a different
data type as appropriate for a given application.
> In case the compiler is theoretically not able to do so, then the
> language could have some construct such as:
> myhash={{k1,v1},{k2,v2},...};
> AssignListProperty(myhash,hash-like);
You've contradicted yourself. If the compiler provides explicit
sup****t for both array and linked list, and if both utilities are
available at runtime, and the compiler does the right thing of
matching the explicit compiletime request to the corresponding
runtime utility, then both datatypes *are* sup****ted, just like in
Lisp, and the programmer must say which he/she wants, just as in
Lisp. So you say both datatypes shouldn't be sup****ted, and the
programmer shouldn't have to say which is wanted, then you say the
programmer will say which is wanted. Do you see the contradiction?
> Also, as a consequence of the cons thing, lisp creates many
> various ways to code a tree of a given shape. (i.e. the
> distinction of "proper list")
That's a good thing (in lisp). In your favorite Mathematica, the
only kind of tree you can get is nested lists, which you can get in
Lisp just the same. Unfortunately nested lists don't provide any
way to automatically rebalance the tree as new elements are added
to it. If the programmer adds that capability to the basic form of
nested lists, to make an AVL tree or red/black tree etc. etc., then
you have just as many ways to implement a tree in either language,
and the programmer (either the application programmer, or some
third-party package vendor) must explicitly code for that
particular kind of self-balancing tree, so the difference you
complain about isn't a difference at all.
> the whole source code of any source code is one single, deeply nested
list.
Is that supposed to be English??
Before you re-post URLs pointing to stuff you wrote long ago which
you've archived in your personal Web site, why don't you proofread?
By the way, the parse tree of *any* high-level-language program is
a deeply nested list/tree. (The raw syntax of any such program is
just a sequence of characters, which requires a parser to turn into
anything meaningful, i.e. the parse tree.)
> Mathematica ... provide many facilities to manipulate such a
> form. I can, for example, get all the nodes at level n.
How is that of any general use?? I can't think of even once I've
ever wanted a nested list flattened down to the third level, for
example.
> Map a function to level n.
Ditto. Totally useless mapping utility.
> Map a function to just leafs (which is considered level -1 in
> Mathematica).
How do you define a "leaf", if the whole structure is just a bunch
of nested lists, and any *element* can be another list if wanted?
How is the mapping utility suppose to know the difference between
sub-lists which represent more nesting and sub-lists which are
supposed to be leafs themselves??
For example, suppose an application programmer has implemented an
AVL tree, where each node in the tree looks like one of these:
(FORK <depth> <leftSubtree> <righSubtree>)
(LEAF <value>)
How is the built-in utility supposed to know that when it sees a
FORK node it's supposed to explore through only the third and
fourth sub-lists, while when it sees a LEAF node it's supposed to
*stop* there but use just the second sub-list, not use the whole
node itself? Answer: The built-in utility can't possibly know the
programmer's intent what leaves are supposed to be, hence the
utility is worthless.
> Dispite being a expert in trees, the lisp's cons business is
> truely a pain to deal with.
You need to proofread your English! You say there that lisp's cons
business is an expert in trees. Is that what you really meant to
say? Did you intend to say that *you* are an expert in trees?
That's not what you actually said. Please proofread and correct
your Web pages before re-posting links to them.
> To work with anything slightly nested, is a pain in Perl.
Yeah, Perl sucks when it comes to nested lists. Lisp doesn't suck.
You weaken your argument by pretending Perl and Lisp are the same,
and trying to use Perl's weakness as if a Lisp weakness.
|
