Re: reading file to list

Rhodri James wrote:

> I *was* thinking of code produced in the real world, and I don't buy
> your assertion. I'm not an academic, and I wouldn't hesitate to lay
> down a line of code like that. As I said before, it fits into English
> language idioms naturally, and as a result is pretty self-descriptive.

As a non-native speaker and non-academic, I don't understand the "fittine
into English language idioms naturally" which is mentioned here in the
different subthreads. Could you try to explain that for me?

TIA

--
Cheerz Lars

Lars Behrens

Lars Behrens wrote:

> As a non-native speaker and non-academic, I don't understand the "fittine
"fitting", I meant. Sorry ^^

--
Cheerz Lars

Lars Behrens

Xah Lee wrote:
> On Jan 19, 11:17 pm, alex23 <wuwe...@gmail.com> wrote:
> ...
[...]
> sure. In a political context, many criticism or description of the
> situation from one party can be seen as ad hominem attack. I feel that
> that many old emacs users, which includes significant portion of emacs
> developers (if not majority), are so exteremly bottled up and turn
> down any possibility of advancing. They are killing emacs. (similar
> feelings for most regular posters here in comp.lang.lisp )
>
This might have been relevant if you had not been too stupid to observe
that you are (sigh, yet again) posting irrelevant drivel to
comp.lang.python. Please stop.

[...]
> Your input will be highly valued. Though, forgive me to say, that i
> think my opinion on this is beyond any computer scientist of any
> standing can try to tell me otherwise. If they disagree (which i think
> most of them won't), i think their knowledge and experience in the
> area of computer languages and syntax and notations, IQ, are inferior
> to me.
>
How very comforting for you. "Closed mind" hardly begins to describe
that attitude.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Steve Holden

On Wed, 21 Jan 2009 09:42:19 -0000, Lars Behrens <>
wrote:

> Rhodri James wrote:
>
>> I *was* thinking of code produced in the real world, and I don't buy
>> your assertion. I'm not an academic, and I wouldn't hesitate to lay
>> down a line of code like that. As I said before, it fits into English
>> language idioms naturally, and as a result is pretty self-descriptive.
>
> As a non-native speaker and non-academic, I don't understand the "fittine
> into English language idioms naturally" which is mentioned here in the
> different subthreads. Could you try to explain that for me?

It just means that the progamming language concept in question has the
same "shape" (i.e. roughly the same syntax) as an English language
syntactic construct in common use. So for list comprehensions we have

[ f(x) for x in l ]

and

"Make a list of f(x) for each x in the list l."

You can see how the elements of the list comprehension fit sequentially
into the English sentence. As other people have pointed out, this
particular example really comes from the mathematical notation for
constructing sets:

f(x) ∀ x ∊ l

....but it's no accident that they both "translate" straightforwardly
into English!

--
Rhodri James *-* Wildebeeste Herder to the Masses

Rhodri James

On Wed, 21 Jan 2009 09:13:03 -0000, Xah Lee <> wrote:

> Rhodri James wrote:
>> I recommend spending less time being certain that you are correct
>> without seeking evidence
>
> I don't concur.
>
> For instance, when you are talking to a bunch of kids, you have to be
> sure of yourself, else they run all over you, even if they didn't mean
> to be rude.

So you would rather give the appearance of authority than do the work
to actually have authority? This is very poor teaching practice.

> Also, one's demeanor must commensurate one's knowledge. If i pamper
> you, you might think i'm a whimp, and run on with your opinions and
> thoughts unbridled, which, can be considered as a miscommunication on
> my part.

As it is, I think your demeanor wildly outstrips your knowledge,
something you have just confirmed. This attitude makes you a highly
unreliable source of information.

*plonk*

--
Rhodri James *-* Wildebeeste Herder to the Masses

Rhodri James

Rhodri James wrote:
> *plonk*

Please see:

• Killfile Considered Harmful
http://xahlee.org/UnixResource_dir/w...e_harmful.html

plain text version follows
---------------------------
Killfile Considered Harmful

Xah Lee, 2000-02-26

In newsgroups, killfile is a playful word meaning that the poster has
placed someone in a blacklist of authors, where their postings will be
automatically hidden from view in their newsreader. Such functionality
of newsreaders originated in unix. In the early 90s or before, it used
to be referred to as “sending someone into /dev/null�, because “/dev/
null� can be used as a way for deleting email program outputs.

The killfile behavior, is simply put: “sweep-under-the-rug�, “bury-
head-in-sand� kind of behavior. Imagine that in a gathering where if
everyone totally ignores other's voices except their own kind, then
what cacophony would result? Similarly, if we ignore the problem of
crime by simply using larger locks for our own doors, what consequence
would result?

We are all human beings. Our surroundings are our organs and affects
us dearly. In newsgroups, inevitably there will be certain individuals
with foul breath at times. Killfile mechanism is a very good feature
to battle such annoyances. This is not a reason for falling for the
convenience of blocking your ears from dissenting voices or the
nonconformists.

The worst thing i hate about it, is the broadcasting of someone being
killfiled. Oftentimes the sole content of a message is “You've been
killfiled�. WHAT GOOD DOES IT DO TO THE COMMUNITY BY SUCH
ANNOUNCEMENT? Is it a warning system for fellow readers to prepare to
follow suit? Or is it a stupid self-righteous act? In the course of a
unpleasant encountering, the killfilers feel the other party being
unworthy of further response but they don't want to be seen as
chickening out so they had to announce it as if saying: “Hello world:
you don't see a returning '**** you' from me because _I_ am _smarter_
and took a step ahead of my antagonist and covered my ears, not
because he is correct or anything like that.�. Pride is a human
nature, but unqualified conceit is despicable.

A second motivation for announcing killfile is more explicitly
juvenile. Killfile has several variant names: “You've been
killfiled.�, “plonk� (sound of falling object), “I've send you to /dev/
null� (unixism), and creativity does not seems to cease there, e.g. in
comp.lang.lisp: (plonk 'xah) or signatures that reads “in /dev/null,
they can't hear you scream.�

The reason of these playful variations is precisely literary folly.
The utterer delights in its use since most are wanting of genuine
literary artistry. This adds to the fashion of killfile and its
broadcasting.

Killfile behavior and broadcasting have another curious trait: No
burden of commitment. One cannot really tell if the person really did
the killfile. The decision to make a killfile cry in public does not
carry any weight of responsibility as compared to making a claim,
stating a “fact�, or expressing a opinion. It is simply a variation of
“**** you�. This too, contributed to its uncontrolled popularity.

Xah
∑ http://xahlee.org/

☄

Xah Lee

André Thieme wrote:

> (map #(map (fn [s] (Integer/parseInt s)) (.split % "\\s")) (line-seq
> (reader "blob.txt")))

An error results:

java.lang.Exception: Unable to resolve symbol: reader in this context

This works:

(map #(map (fn [s] (Integer/parseInt s)) (.split % "\\s"))
(.split (slurp "junk") "\r?\n"))

William James

On 17 Jan, 17:16, Xah Lee <xah...@gmail.com> wrote:
> 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.)

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

nick_keighley_nospam@hotmail.com

On 24 Feb, 15:00, nick_keighley_nos...@hotmail.com wrote:
> On 17 Jan, 17:16, Xah Lee <xah...@gmail.com> wrote:

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

<snip>

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

an assignment-free version

(define (read-line port)
(define (rec-read-line port line)
(let ((next-char (peek-char port)))
(cond ((eof-object? next-char) '())
((char=? next-char #\newline) (read-char port) line)
((char-numeric? next-char)
(let ((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)
(let ((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)))

(define (mk) (make-list-from-text "blob.txt"))

<snip>

number was originally define'd but I discovered there were
limits to where you could define things

nick_keighley_nospam@hotmail.com

On 17 Jan, 17:16, Xah Lee <xah...@gmail.com> wrote:
> comp.lang.lisp,comp.lang.scheme,comp.lang.function al,comp.lang.python,comp.*lang.ruby

<snip>

> The lisp's cons fundamentally makes nested list a pain to work with.
> Lisp's nested syntax makes functional sequencing cumbersome.

so hide it

(define (make-list stream eos?)
(let ((atom (stream)))
(if (eos? atom)
'()
(cons atom (make-list stream eos?)))))

(define (make-int-list port)
(make-list (lambda () (read-line port)) null?))

the nasty cons then only appears in a single function which
you can hide in a library


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

is my code to build a list that bad?


> 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

I read it. Your point seems to be "cons becomes difficult
with deeply nested structures". Could you give an example?

nick_keighley_nospam@hotmail.com