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.)
-----------------
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
Xah
∑ http://xahlee.org/
☄
--
http://mail.python.org/mailman/listinfo/python-list
