On 17 Jan, 17:16, Xah Lee <xah...@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_...@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
--
http://mail.python.org/mailman/listinfo/python-list
