André Thieme wrote:
> Xah Lee schrieb:
> > comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.pytho
> > n,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))
> >
> > 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.
>
> *Of course* Xah is wrong, as always.
> Who would expect anything else?
> In the Lisp style Clojure for example one does exactly the same as
> Jillian James (JJ) did in Ruby:
> (map #(map (fn [s] (Integer/parseInt s)) (.split % "\\s")) (line-seq
> (reader "blob.txt")))
That fails when numbers are separated by more than one space.
And what about leading or trailing space?
>
> This is slightly longer, simply because the functions have longer
> names. Integer/parseInt vs to_i
>
> Also the function split takes a regexp, so I have to add the "\\s"
> here. I don’t know though if Jillians version also handles any
> kind of whitespac per line.
irb(main):003:0> puts " foo \t bar "
foo bar
=> nil
irb(main):004:0> " foo \t bar ".split
=> ["foo", "bar"]
irb(main):005:0> "foo...bar?-!hoo".split /\W+/
=> ["foo", "bar", "hoo"]
> And the last thing is, that the function reader returns a
> BufferedReader. So in general this is more valuable in real programs
> as opposed to one- line scripts. If we combine line-seq and reader
> into readline and apply the two other changes we would say:
> (map #(map (fn [s] (to_i s)) (.split %)) (readlines "blob.txt"))
That is not a complete program.
> vs
> IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}
That is the complete program.
>
> So, obviously Xah is far away from any reality.
> It took him hours of his life to write up all his ideas about Lisp.
> Sad to see that all that time was wasted. All of it was wrong.
> Poor Xah :(
>
>
> And btw, Drew Krause is just a Lisp newbie. No Lisper would ever store
> data for his programs in the format
> 3 10 2
> 4 1
> 11 18
>
> but instead as
> (3 10 2)
> (4 1)
> (11 18)
Perhaps the data was stored by someone else. Understand?
>
> And then read it back into the program with:
> (map read-string (line-seq (reader "blob.txt")))
>
You make a very strong case that Lisp is very feeble at
processing data. I'm almost convinced.
Ruby isn't feeble, so data like this is fine:
shall we begin?
or lotus135? 1984 times!
The 3 stooges: COBOL,LISP,FORTRAN.
3.14, si11y L00KING
Extracting the unsigned integers:
IO.readlines('data').map{|s| s.scan(/\d+/).map{|s| s.to_i}}
==>[[], [135, 1984], [3], [3, 14, 11, 0]]
--
http://mail.python.org/mailman/listinfo/python-list
