Re: Cons cell archaic!?

(Part 3 of multi-part reply:)
From: "xah...@xxxxxxxxx" <xah...@xxxxxxxxx>
Now, a little speculation.
We might wonder, why lisp has the cons problem and was never
addressed?

That question presumes a fact not in evidence.
Instead, there never was a cons problem in the first place.

Having data as a single manipulatable object (list) didn't really
become popular until the 1990s. (notably by Perl)

Are you saying that in Perl you can manipulate an entire list as a
unit but you can't manipulate any lesser part of it by itself?

In Perl, what is the cost in time and new storage of each different
kind of list operation? For example, if a list has N elements, does
it take N or log(n) time units to make a new list that has one
additional element at the start or end or in the middle? Or is that
information hidden from users, so they have no idea whether doing
such an operation on a list of fifty billion elements is going to
be reasonable or too slow? In Lisp, using a linked list, it's
clearly known how long such an operation would take:
- Tacking on an additional element at start takes time 1 and uses 1
new unit of memory.
- Tacking on an additional element at end destructively takes time
N and uses 1 new unit of memory.
- Tacking on an additional element at end non-destructively takes
time N and uses N new units of memory.
- Tacking on an additional element at middle destructively takes time
N/2 and uses 1 new unit of memory.
- Tacking on an additional element at end non-destructively takes
time N/2 and uses N/2 new units of memory.
How does that compare with equivalent operations in Perl??

The lisp's cons, as a underlying primitive that builds lists, even
though a bit cumbersome, but works just fine when list structure are
simple.


It's not cumbersome at all. And it works fine for complicated list
structure too.

Even today, with all the perl, python, php, javascript etc
langs that deal with lists, vast majority of list usage is just simple
flat list, sometimes 2 level of nesting (list of list, list of hash,
hash of list). 3 levels of nesting is seldom used unless its 3d
matrices used mostly in computer graphics or linear algebra
applications. Greater than 3 level is almost never seen.

That's totally stupid. There are many uses for unlimited-depth
lists, and if it's not done in those other languages it must be
because those languages make it too difficult, or the type of
people who use those other languages simply aren't bright enough to
think of how to use deeply nested lists. Consider for example
mathematical expressions. Not simple polynomials, which require
only three levels of list in general notation, or one level in
specialized notation, but more complicated expressions such as the
quadradic formula:
-b +/= sqrt(b^2 - 4*a*c)
------------------------
2*a
Did I remember it correctly? I memorized it in high school or
earlier, and it seems to have stuck with me. Working from the 4*a*c
outward, that's one level for the multiplication, one level for the
subtraction, one level for the square root, one level for the
addition or subtraction, and one level for the division. Five
levels right there!! I'm sure you can think of a mathematical
expression that is needs more than five levels of nested structure
if you put your brain to it. For example, try a problem in
first-semester differential calculus, involving a trigonometric
function of a linear transformation, with something multiplied
on the outside. For example, start with
f(x) = cos(x) * sin(x/2 + pi)
which is four levels deep on the right side, and then try to take
the first derivative using the product rule at the top and other
rules in the various terms:
df(x)/dx = d cos(x)/dx * sin(x/2 + pi)
+ cos(x) * d sin(x/2 + pi)/dx 5 levels deep now
= -sin(x) * sin(x/2 + pi)
+ cos(x) * (cos(x/2 + pi) * d (x/2)/dx) 6 levels deep now
= -sin(x) * sin(x/2 + pi)
+ cos(x) * (cos(x/2 + pi) * 1/2) still 6 levels deep
= -sin(x) * sin(x/2 + pi)
+ 1/2 * cos(x) * cos(x/2 + pi) flattened to 5 levels
Now try taking the second derivative. How many levels deep does it get?

As a completely different appliation, consider a multi-level search
process, such as a cladogram or taxonomy:
(life
(cellular
(prokaryote
(eubacteria ...)
(archea ...))
(eukaryote
(protist ...)
(fungi ...)
(plant ...)
(animal
(protozoa ...)
(metazoa
(round ...)
(bilaterallySymmetric
(proterostomes ...)
(deuterostomes ...))))))
(viral
(RNA ...)
(DNA ...))
(computer
(worm ...)
(virus ...)
(trojan ...)))
I've used ... to indicate where several more levels of structure
need to be included. Some species would be located about twenty
levels down from the top. Why can't that be expressed in Perl??

Systematic manipulation and exploitation of nested list, such as
mapping to leafs, to particular level, transposition by permutation
on level, or list structure pattern matching in today's functional
langs, etc is hardly ever to be seen.

Why isn't it seen? Because your eyes are closed so you can't see
what's plainly there? Or do those other languages really make it
too hard to do anything like that? Is Lisp the only language that
makes it easy enough to be practical?

Will Lisp ever be Popular?

Yeah, as soon as some other lispers join me in creating a master
directory to all the libraries per which intentional datatypes they
deal with, whereby it'll be as easy to find the appropriate library
for Lisp as it already is for Java. Then newcomers considering
which language to try for their task will be able to look at both
Java and Lisp as languages worth consiering, and they'll choose
Lisp because it's a lot easier to actually use than Java is. Then
word will get around how easy it is to perform all sorts of tasks
in Lisp, and more and more people will convert to Lisp, and Lisp
will become popular.

Mathematica today sells for over 2 thousands dollars.

Ouch!!! That's horribly expensive. I thought $400 for Macintosh
Allegro Common Lisp was too expensive, which is why I never
upgraded from version 1.2.2 that I got for free from work to a
newer version that would work on my Macintosh Performa. Who in
their right mind would pay that much for Mathematica?

... due to ... the internet and its consequences, e.g. Wikipedia,
youtube, ... computer languages are proliferating like never
before. (e.g. Erlang, OCaml, Haskell, PHP, Ruby, C#, F#, Perl6,
Arc, NewLisp, Scala, Groovy, Lua, Q, Qz, Mercury, Scratch, Flash,
Processing, (see Proliferation of Computing Languages)

Do *any* of those languages have a well-documented directory to all
available libraries (both built-in vendor-supplied and third-party
add-on) in a format as easy to browse as the Java API published by Sun?
<http://java.sun.com/j2se/1.4.2/docs/api/overview-summary.html>
If so, please post the URL of any such nicely organized API spec.
(Note: The CLHS isn't as nicely organized, and isn't as easy for
newcomers to understand, compared to the Java API, IMO.)

** Finished my three-part reply **
.

Relevant Pages

  • Re: Is anything easier to do in java than in lisp?
    ... And any experienced lisp ... in java generally you hardly ever use ... static String showInputDialog(Component parentComponent, ... which was about generic sequences (lists ...
    (comp.lang.java)
  • Re: Is anything easier to do in java than in lisp?
    ... And any experienced lisp ... in java generally you hardly ever use ... static String showInputDialog(Component parentComponent, ... which was about generic sequences (lists ...
    (comp.lang.lisp)
  • Re: Is anything easier to do in java than in lisp?
    ... Is there any real difference between lisp ... debugging environments that allow introspection and Java debugging ... in java working with linked lists must be an awful pain. ...
    (comp.lang.java)
  • Re: Is anything easier to do in java than in lisp?
    ... Is there any real difference between lisp ... debugging environments that allow introspection and Java debugging ... in java working with linked lists must be an awful pain. ...
    (comp.lang.lisp)
  • Re: What OReilly knows about Lisp
    ... "Writing Excel Macros with VBA, ... Languages" and in this appendix the section "F.8. ... LISP" has to say ... T if the lists are equal and F otherwise ...
    (comp.lang.lisp)