reading file to list

nick_keighley_nospam at nick_keighley_nospam at
Wed Feb 25 12:34:33 CET 2009

On 17 Jan, 17:16, Xah Lee <xah... at> wrote:
> comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.­lang.ruby


> The lisp's cons fundamentally makes nested list a pain to work with.
> Lisp's nested syntax makes functional sequencing cumbersome.

so hide it

(define (make-list stream eos?)
    (let ((atom (stream)))
        (if (eos? atom)
            (cons atom (make-list stream eos?)))))

(define (make-int-list port)
    (make-list (lambda () (read-line port)) null?))

the nasty cons then only appears in a single function which
you can hide in a library

> In the ruby code, its post-fix sequential notation (as a side effect
> of its OOP notation) brings out the beauty of functional sequencing
> paradigm (sometimes known as functional chain, sequencing, filtering,
> unix piping).
> its list, like all modern high level langs such as perl, php, python,
> javascript, don't have the lisp's cons problem. The cons destroys the
> usability of lists up-front, untill you have some at least 2 full-time
> years of coding lisp to utilize cons properly. (and even after that,
> it is still a pain to work with, and all you gain is a bit of speed
> optimization in rare cases that requires largish data, most of which
> has better solutions such as a database.)

is my code to build a list that bad?

> Both of these problems i've published articles on.
> For more detail on the cons problem, see
> the section “The Cons Business” at
> • Fundamental Problems of Lisp

I read it. Your point seems to be "cons becomes difficult
with deeply nested structures". Could you give an example?

More information about the Python-list mailing list