Re: reading file to list

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))
> > 
> > [e-mail] 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窶冲 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]]