On Feb 25, 3:34 am, nick_keighley_nos...@hotmail.com wrote:
> the nasty cons then only appears in a single function which
> you can hide in a library
I think the following answers that.
Q: If you don't like cons, lisp has arrays and hashmaps, too.
A: Suppose there's a lang called gisp. In gisp, there's cons but also fons. Fons are just like cons except it has 3 cells with 3 accessors: car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in the lang. Every some 100 lines of code you'll see a use of fons with its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar, etc. You got annoyed by this. You as a critic, complains that fons is bad. But then some gisp fanatics retorts: “If you don't like fons, gisp has cons, too!”.
You see, by “having something too”, does not solve the problem of pollution. Sure, you can use just cons in gisp, but every lib or other's code you encounter, there's a invasion of fons with its cbar, cbbar, cbbbar. The problem created by fons does not go away by “having cons too”.
above is from
• Fundamental Problems of Lisp
> I read it. Your point seems to be "cons becomes difficult
> with deeply nested structures". Could you give an example?
There are few examples in these articles:
• The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations
the above, 3rd section, gives detail about the problems of fully
nested syntax. In particular, it shows a source code snippet of language with fully nested syntax, but is not lisp, so that lispers can get a fresh impression.
• A Ruby Illustration of Lisp Problems
the above, is a concrete example of showing how full nesting is cumbersome, by constrasting a simple program in Ruby and lisp.
• Why Lisp Do Not Have A Generic Copy-List Function
the above, shows the cons problem, by looking at Kent Pitman's article with a different perspective.
A short Plain Text Excerpt of the ruby article cited above follows.
More specifically, 2 fundamental problems of lisp i feel this ruby example illustrates well:
• the cons impedes many aspects of lists. e.g. difficult to learn, confusing, hard to use, prevent development of coherent list manipulation functions.
• nested syntax impedes the functional programing paradigm of function chaining, esp when each function has 2 or more arguments (e.g. map).
here's a short summary of the nesting problem:
(map f x) ; 1 level of chaining
(map g (map f x)) ; 2 levels
(map h (map g (map f x))) ; 3 levels
x | f | g | h ----> unix pipe
x // f // g // h ----> Mathematica
h @ g @ f @ x ----> Mathematica
h g f x -------> some functional langs, Haskell, Ocaml
The way the above works is that each of f, g, h is a lambda themselves
that maps. (that is, something like “(lambda (y) (map f y))”)
Note, that any of the f, g, h may be complex pure functions (aka lambda). Because in lisp, each lambda itself will in general have quite a lot nested parens (which cannot be avoided), so this makes any chaining of functions of 2 args, for more than 2 or 3 levels of nesting, unusable for practical coding. One must define the functions separately and just call their names, or use function composition with lambda (which gets complex quickly). One major aspect of this problem is that the scope of vars becomes hard to understand in the deep nested source code. This is worse in elisp, because emacs is dynamically scoped, so you have to avoid using var of same name.