reading file to list

[nick_keighley_nospam at hotmail.com]

On 17 Jan, 17:16, Xah Lee <xah... at gmail.com> wrote:
> comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.­lang.ruby
>
> Here's a interesting toy problem posted by Drew Krause to
> comp.lang.lisp:
>
> ------------------------
> On Jan 16, 2:29 pm, Drew Krause wrote [paraphrased a bit]:
>
> OK, I want to create a nested list in Lisp (always of only integers)
> from a text file, such that each line in the text file would be
> represented as a sublist in the 'imported' list.
>
> example of a file's content
>
> 3 10 2
> 4 1
> 11 18
>
> example of programing behavior
> (make-list-from-text "blob.txt") => ((3 10 2) (4 1) (11 18))
>
> -----------------
> Here's a emacs lisp version:
>
> (defun read-lines (file)
>   "Return a list of lines in FILE."
>   (with-temp-buffer
>     (insert-file-contents file)
>     (split-string
>      (buffer-substring-no-properties 1 (point-max)) "\n" t)
>     )
>   )
>
> (defvar mylist '() "result list" )
> (setq mylist '()) ; init in case eval'd again
>
> (mapc
>  (lambda (x) (setq mylist
>                    (cons (split-string x " ") mylist )) )
>  (read-lines "xxblob.txt")
>  )
>
> The above coding style is a typical maintainable elisp.
>
> In a show-off context, it can be reduced to by about 50%, but still
> far verbose than ruby or say perl (which is 1 or 2 lines. (python
> would be 3 or 5)).
>
> Note that the result element is string, not numbers. There's no easy
> way to convert them on the fly. 3 or so more lines will be needed to
> do that.
>
> The “read-lines” function really should be a built-in part of elisp.
> It is not so mostly because emacs people have drawn themselves into a
> elitist corner, closing off to the outside world. (i am sending a
> suggestion to the official emacs dev list on adding read-line now.)

scheme:

(define (read-line port)
    (define (rec-read-line port line)
        (define next-char (peek-char port))
        (define number #f)
        (cond ((eof-object? next-char) '())
              ((char=? next-char #\newline) (read-char port) line)
              ((char-numeric? next-char)
                   (set! number (read port))
                   (cons number (rec-read-line port line)))
              ((char=? next-char #\space)
                   (read-char port)
                   (rec-read-line port line))
              (else (error (string-append "bad character \""
                              (string next-char) "\"")))
    ))

    (rec-read-line port '())
)

(define (make-int-list port)
    (define line (read-line port))
    (if (null? line)
        '()
        (cons line (make-int-list port))))

(define (make-list-from-text file)
    (make-int-list (open-input-file file)))



> -----------------
>
> w_a_x_... at yahoo.com gave a ruby solution:
>
>   IO.readlines("blob.txt").map{|line| line.split }
>
> augumented by Jilliam James for result to be numbers:
>
>   IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}
>
> Very beautiful.
>
> -------------------
>
> That's really the beauty of Ruby.
>
> This problem and ruby code illustrates 2 fundamental problems of lisp,
> namely, the cons problem, and the nested syntax pain. Both of which
> are practically unfixable.
>
> The lisp's cons fundamentally makes nested list a pain to work with.
> Lisp's nested syntax makes functional sequencing cumbersome.
>
> 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.)
>
> 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
>  http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> For more detail on the nested syntax problem for function chaining,
> see
> the section “How Purely Nested Notation Limits The Language's Utility”
> at:
>
> • The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Nested Notations
>  http://xahlee.org/UnixResource_dir/writ/notations.html