reading file to list
xahlee at gmail.com
Wed Feb 25 19:18:17 CET 2009
On Feb 25, 3:34 am, nick_keighley_nos... at 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
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
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 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
• 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.
More information about the Python-list