Re: reading file to list

comp.lang.lisp,comp.lang.scheme,comp.lang.function al,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 1)

-----------------
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/w..._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/

☄

Xah Lee

On Jan 17, 9:16 am, Xah Lee <xah...@gmail.com> wrote:
> Here's a interesting toy problem posted by Drew Krause to
> comp.lang.lisp:
> ...

The code in my previous elisp code got a bump. It should be:

(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)
)
)

(mapcar
(lambda (x) (split-string x " ") )
(read-lines "xxblob.txt")
)

The article is now archived at:

• A Ruby Illustration of Lisp Problems
http://xahlee.org/UnixResource_dir/w...s_by_ruby.html

Xah
∑ http://xahlee.org/

☄

Xah Lee

Tino Wildenhain wrote:
> Xah Lee wrote:
>> comp.lang.lisp,comp.lang.scheme,comp.lang.function al,comp.lang.python,comp.lang.ruby
>>
>>
> ...
>> 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 1)
>
>>
>> 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)).
>
> So? Please count the lines:
>
> [line.strip().split() for line in file("blob.txt")]
>
The original requirement was for a list of lists of integers:

[[int(x) for x in line.split()] for line in open("blob.txt")]

Still only 1 line, though.

MRAB

On Jan 17, 9:34 am, Xah Lee <xah...@gmail.com> wrote:
> The code in my previous elisp code got a bump. It should be:
> ...
> • A Ruby Illustration of Lisp Problems
> http://xahlee.org/UnixResource_dir/w...s_by_ruby.html

Sorry again. More correction:

(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)
)
)

(mapcar
(lambda (x)
(mapcar
(lambda (y) (string-to-number y) )
(split-string x " ")
)
)
(read-lines "xxblob.txt")
)

this is last post of correction.

Xah
∑ http://xahlee.org/

☄

Xah Lee

Xah Lee schrieb:
> comp.lang.lisp,comp.lang.scheme,comp.lang.function al,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 1)
>
> 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")))

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.
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"))
vs
IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}

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 1

And then read it back into the program with:
(map read-string (line-seq (reader "blob.txt")))


André
--

André Thieme

Xah Lee wrote:
> • A Ruby Illustration of Lisp Problems
> http://xahlee.org/UnixResource_dir/w...s_by_ruby.html


On Jan 17, 12:30 pm, André Thieme <address.good.until.
2009.may...@justmail.de> wrote:


> 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")))

Note that you have nested map. This is a problem of function chaning
as i detailed.

The other problem of cons, is commonly seen. Just about every week, we
see some perhaps beginning lisper asking how to do various trivial
list
manipulation problem, which you don't see such question or frequency
in any of modern high level lang forms.

The frequently asked list manipulation question we see include how to
append, prepend, or anything involving nested list such as
partitioning, reordering sublists, getting leaves, interpretation of
leaves, etc. This is caused by the cons.

associated lisp problem compound the issue. Namely, the not exactly
regular syntax, and the eval model of sometimes symbol sometimes
uneval'd symbol, e.g. “'(...)�, “`(...,@ ...)� things.

The clojure example you gave above, apparently inherited the irregular
syntax problem. (you see the #, [], % things, which is breaks the
lisp's sexp idea) Also, all modern lisp basically all get ****ed up by
inheriting the cons (e.g. clojure, NewLisp, Arc lisp, Liskell). Often,
they change the semantic a bit apparently as a mesaure towards solving
the cons problem. (and Qi Lisp creates a huge bag of ad hoc, extremely
ugly, syntax soup)

Advice: if you are creating a lispy lang, two things:

• stick to a _pure_ nested syntax, no exception whatsoever. (e.g. no
more ` ' # % shits) If you want, add a transparent layer on top to
support arbitrary algeraic notation. (e.g. look at Mathematica, CGOL)

• get rid of the cons. (you can still implement the so-called linked
list, but no where it should be shown to the programer)

Further readings:

• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/w..._problems.html

Xah
∑ http://xahlee.org/

☄

Xah Lee

Xah Lee schrieb:
> Xah Lee wrote:
>> • A Ruby Illustration of Lisp Problems
>> http://xahlee.org/UnixResource_dir/w...s_by_ruby.html
>
>
> On Jan 17, 12:30 pm, André Thieme <address.good.until.
> 2009.may...@justmail.de> wrote:
>
>
>> 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")))
>
> Note that you have nested map. This is a problem of function chaning
> as i detailed.

Yes, Jillian also has nested maps:
IO.readlines("blob.txt").map{|line| line.split.map{|s| s.to_i }}


> The other problem of cons, is commonly seen. Just about every week, we
> see some perhaps beginning lisper asking how to do various trivial
> list
> manipulation problem, which you don't see such question or frequency
> in any of modern high level lang forms.

You see questions about trivial problems every week in all forums about
programming languages.
It has nothing to do with conses. Wrong road.


> The frequently asked list manipulation question we see include how to
> append, prepend, or anything involving nested list such as
> partitioning, reordering sublists, getting leaves, interpretation of
> leaves, etc. This is caused by the cons.

Yes, same with all containers in all programming languages.


> The clojure example you gave above, apparently inherited the irregular
> syntax problem. (you see the #, [], % things, which is breaks the
> lisp's sexp idea)

My code used 8 “mysterious symbols�:
( ) # [ ] . " %

The Ruby version had these 7:
( ) | { } . "

And of course, neither in Ruby nor Clojure they break any idea.



> Also, all modern lisp basically all get ****ed up by
> inheriting the cons (e.g. clojure, NewLisp, Arc lisp, Liskell). Often,
> they change the semantic a bit apparently as a mesaure towards solving
> the cons problem. (and Qi Lisp creates a huge bag of ad hoc, extremely
> ugly, syntax soup)

Funny.
What you write is an english text with words that most people can
understand.
You trick them into thinking that it actually makes sense what you say.
It is so technical, that a random would believe it.
But what you really say is about as meaningful as saying that it is
impossible to write good programs in Python, because it adds whitespace
to its syntax.


> • Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/w..._problems.html

You wasted lots of your time. Or was this maybe generated by a bot?
Maybe http://pdos.csail.mit.edu/scigen/ or something like that?
I also found this paper that you wrote:
http://apps.pdos.lcs.mit.edu/scicach...6.Xah+Lee.html
Another crap posting of you. But a random person might be impressed.


André
--

André Thieme

a idiot wrote:
> Yes, Jillian also has nested maps:

the issue here, is not about whether Ruby has nested map or not. It is
about illustrating a lisp problem. In particular, nested syntax
impedes the functional programing paradigm of function chaining.

• A Ruby Illustration of Lisp Problems
http://xahlee.org/UnixResource_dir/w...s_by_ruby.html

a idiot wrote:
> My code used 8 “mysterious symbols�:
> ( ) # [ ] . " %
>
> The Ruby version had these 7:
> ( ) | { } . "

The issue here is not about which lang employs more special chars. The
issue is about the irregularities in lisp's syntax damaged its power
of its otherwise believed superior regular syntax.

• Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/w..._problems.html

Xah
∑ http://xahlee.org/

☄

Xah Lee

On Jan 17, 10:25 am, Tino Wildenhain <t...@wildenhain.de> wrote:
> > [[int(x) for x in line.split()] for line in open("blob.txt")]

Nice (python code).

Few comments:

• the above code is borderline of atypical. e.g. it is not a average
python code would produce or one'd seen in corporate python code.

• voodoo like the above makes me dislike python. To me, the one
advantage of python is its clarity enforced by its syntax.
Specifically, the forced indendation and quite simple semantics.
However, the way i've seen Guido's propensities and how python 3 is
moving to, it is becoming more mumbo jumbo of computer sciency OOP
jargons with syntax soup. (with iterators, enumerators, list
comprehension... shits forced upon the users)

The above line illustrate well the ad hoc syntax soup nature python is
moving into.

Further readings:

• Perl-Python Tutorial: List Comprehension
http://xahlee.org/perl-python/list_comprehension.html

• Lambda in Python 3000
http://xahlee.org/perl-python/python_3000.html

Xah
∑ http://xahlee.org/

☄

Xah Lee

André Thieme wrote:

> Xah Lee schrieb:
> > comp.lang.lisp,comp.lang.scheme,comp.lang.function al,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 1)
> >
> > 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 1

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]]

William James