reading file to list

Xah Lee xahlee at
Tue Jan 20 09:42:07 CET 2009

On Jan 19, 11:17 pm, alex23 <wuwe... at> wrote:

Hi Daniel Weinreb,

Xah wrote:
> • A Ruby Illustration of Lisp Problems
Daniel Weinreb wrote:
> Xah Lee: Elisp is an interesting choice.  But without converting the
> strings to integers, it's not really right.

i did post a correction quickly that includes the conversion to
num. Here's the full code:

(defun read-lines (file)
  "Return a list of lines in FILE."
    (insert-file-contents file)
     (buffer-string) "\n" t)

 (lambda (x)
    (lambda (y) (string-to-number y) )
    (split-string x " ")
 (read-lines "blob.txt")

> It's interesting that Elisp already has a style of reading in the
> whole file, but no built-in to convert strings to integers, whereas
> Common Lisp is the other way around.

> The statement "It is not so mostly because emacs people have drawn
> themselves into a elitist corner, closing off to the outside world" is
> just a rude ad hominem attack.

sure. In a political context, many criticism or description of the
situation from one party can be seen as ad hominem attack. I feel that
that many old emacs users, which includes significant portion of emacs
developers (if not majority), are so exteremly bottled up and turn
down any possibility of advancing. They are killing emacs. (similar
feelings for most regular posters here in comp.lang.lisp )

Now, that statement is imprecise, is attacking, needs a lot
qualifications. I have literally written about 20 articles each a
thousand words or more over the past 3 years that explains many
specific cases in painful detail. (e.g. see
) However, in a one sentence description in this thread's context,
calling them “elitist” and “closing off to the outside world”, is to
the point.

> Your claim that this shows something wrong with lists is completely
> unclear, although if I read your paper (I'll try) I might have some
> idea what you're getting at

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
x.f.g.h        -------> various OOP langs, esp Ruby, javascript
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 detail here:

the section “The Cons Business” at
• Fundamental Problems of Lisp

• The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Nested Notations

Your input will be highly valued. Though, forgive me to say, that i
think my opinion on this is beyond any computer scientist of any
standing can try to tell me otherwise. If they disagree (which i think
most of them won't), i think their knowledge and experience in the
area of computer languages and syntax and notations, IQ, are inferior
to me.


More information about the Python-list mailing list