Re: reading file to list
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 18)) 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On 17 Jan, 17:16, Xah Lee xah...@gmail.com wrote: comp.lang.lisp,comp.lang.scheme,comp.lang.functional,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/writ/lisp_problems.html I read it. Your point seems to be cons becomes difficult with deeply nested structures. Could you give an example? -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Feb 25, 3:34 am, nick_keighley_nos...@hotmail.com wrote: the nasty cons then only appears in a single function which you can hide in a library I think the following answers that. Q: If you don't like cons, lisp has arrays and hashmaps, too. A: Suppose there's a lang called gisp. In gisp, there's cons but also fons. Fons are just like cons except it has 3 cells with 3 accessors: car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in the lang. Every some 100 lines of code you'll see a use of fons with its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar, etc. You got annoyed by this. You as a critic, complains that fons is bad. But then some gisp fanatics retorts: “If you don't like fons, gisp has cons, too!”. You see, by “having something too”, does not solve the problem of pollution. Sure, you can use just cons in gisp, but every lib or other's code you encounter, there's a invasion of fons with its cbar, cbbar, cbbbar. The problem created by fons does not go away by “having cons too”. above is from • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html - I read it. Your point seems to be cons becomes difficult with deeply nested structures. Could you give an example? There are few examples in these articles: • The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations http://xahlee.org/UnixResource_dir/writ/notations.html the above, 3rd section, gives detail about the problems of fully nested syntax. In particular, it shows a source code snippet of language with fully nested syntax, but is not lisp, so that lispers can get a fresh impression. • A Ruby Illustration of Lisp Problems http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html the above, is a concrete example of showing how full nesting is cumbersome, by constrasting a simple program in Ruby and lisp. • Why Lisp Do Not Have A Generic Copy-List Function http://xahlee.org/UnixResource_dir/writ/lisp_equal_copy_list.html the above, shows the cons problem, by looking Kent Pitman's article with a different perspective. A short Plain Text Excerpt of the ruby article cited above follows. -- More specifically, 2 fundamental problems of lisp i feel this ruby example illustrates well: • the cons impedes many aspects of lists. e.g. difficult to learn, confusing, hard to use, prevent development of coherent list manipulation functions. • nested syntax impedes the functional programing paradigm of function chaining, esp when each function has 2 or more arguments (e.g. map). here's a short summary of the nesting problem: (map f x) ; 1 level of chaining (map g (map f x)) ; 2 levels (map h (map g (map f x))) ; 3 levels compare: x | f | g | h unix pipe x // f // g // h Mathematica h @ g @ f @ x Mathematica x.f.g.h--- various OOP langs, esp Ruby, javascript h g f x --- some functional langs, Haskell, Ocaml The way the above works is that each of f, g, h is a lambda themselves that maps. (that is, something like “(lambda (y) (map f y))”) Note, that any of the f, g, h may be complex pure functions (aka lambda). Because in lisp, each lambda itself will in general have quite a lot nested parens (which cannot be avoided), so this makes any chaining of functions of 2 args, for more than 2 or 3 levels of nesting, unusable for practical coding. One must define the functions separately and just call their names, or use function composition with lambda (which gets complex quickly). One major aspect of this problem is that the scope of vars becomes hard to understand in the deep nested source code. This is worse in elisp, because emacs is dynamically scoped, so you have to avoid using var of same name. Xah ∑http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Feb 25, 10:18 am, Xah Lee xah...@gmail.com wrote: On Feb 25, 3:34 am, nick_keighley_nos...@hotmail.com wrote: the nasty cons then only appears in a single function which you can hide in a library I think the following answers that. Q: If you don't like cons, lisp has arrays and hashmaps, too. A: Suppose there's a lang called gisp. In gisp, there's cons but also fons. Fons are just like cons except it has 3 cells with 3 accessors: car, cbr, cdr. Now, gisp is a old lang, the fons are deeply rooted in the lang. Every some 100 lines of code you'll see a use of fons with its extra accessor cbr, or any one of the cbaar, cdabr, cbbar, cbbbar, etc. You got annoyed by this. You as a critic, complains that fons is bad. But then some gisp fanatics retorts: “If you don't like fons, gisp has cons, too!”. You see, by “having something too”, does not solve the problem of pollution. Sure, you can use just cons in gisp, but every lib or other's code you encounter, there's a invasion of fons with its cbar, cbbar, cbbbar. The problem created by fons does not go away by “having cons too”. above is from • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html - I read it. Your point seems to be cons becomes difficult with deeply nested structures. Could you give an example? There are few examples in these articles: • The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations http://xahlee.org/UnixResource_dir/writ/notations.html the above, 3rd section, gives detail about the problems of fully nested syntax. In particular, it shows a source code snippet of language with fully nested syntax, but is not lisp, so that lispers can get a fresh impression. • A Ruby Illustration of Lisp Problems http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html the above, is a concrete example of showing how full nesting is cumbersome, by constrasting a simple program in Ruby and lisp. • Why Lisp Do Not Have A Generic Copy-List Function http://xahlee.org/UnixResource_dir/writ/lisp_equal_copy_list.html the above, shows the cons problem, by looking Kent Pitman's article with a different perspective. A short Plain Text Excerpt of the ruby article cited above follows. -- More specifically, 2 fundamental problems of lisp i feel this ruby example illustrates well: • the cons impedes many aspects of lists. e.g. difficult to learn, confusing, hard to use, prevent development of coherent list manipulation functions. • nested syntax impedes the functional programing paradigm of function chaining, esp when each function has 2 or more arguments (e.g. map). here's a short summary of the nesting problem: (map f x) ; 1 level of chaining (map g (map f x)) ; 2 levels (map h (map g (map f x))) ; 3 levels compare: x | f | g | h unix pipe x // f // g // h Mathematica h @ g @ f @ x Mathematica x.f.g.h--- various OOP langs, esp Ruby, javascript h g f x --- some functional langs, Haskell, Ocaml The way the above works is that each of f, g, h is a lambda themselves that maps. (that is, something like “(lambda (y) (map f y))”) Note, that any of the f, g, h may be complex pure functions (aka lambda). Because in lisp, each lambda itself will in general have quite a lot nested parens (which cannot be avoided), so this makes any chaining of functions of 2 args, for more than 2 or 3 levels of nesting, unusable for practical coding. One must define the functions separately and just call their names, or use function composition with lambda (which gets complex quickly). One major aspect of this problem is that the scope of vars becomes hard to understand in the deep nested source code. This is worse in elisp, because emacs is dynamically scoped, so you have to avoid using var of same name. Here's a actual lisp code. I don't consider it readable, due to the profusion of parens. (defun lisp-complete-symbol (optional predicate) Perform completion on Lisp symbol preceding point. Compare that symbol against the known Lisp symbols. If no characters can be completed, display a list of possible completions. Repeating the command at that point scrolls the list. When called from a program, optional arg PREDICATE is a predicate determining which symbols are considered, e.g. `commandp'. If PREDICATE is nil, the context determines which symbols are considered. If the symbol starts just after an open-parenthesis, only symbols with function definitions are considered. Otherwise, all symbols with function definitions, values or properties are considered. (interactive) (let ((window (get-buffer-window *Completions* 0))) (if (and (eq last-command this-command) window (window-live-p window) (window-buffer window) (buffer-name (window-buffer window))) ;; If this command was repeated, and
Re: reading file to list
On 17 Jan, 17:16, Xah Lee xah...@gmail.com wrote: 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.) 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/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 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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)) -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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. 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. Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Lars Behrens wrote: As a non-native speaker and non-academic, I don't understand the fittine fitting, I meant. Sorry ^^ -- Cheerz Lars -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Wed, 21 Jan 2009 09:42:19 -, Lars Behrens spam.bus...@web.de 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Wed, 21 Jan 2009 09:13:03 -, Xah Lee xah...@gmail.com 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Rhodri James wrote: *plonk* Please see: • Killfile Considered Harmful http://xahlee.org/UnixResource_dir/writ/kill_file_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 'fuck 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 “fuck you”. This too, contributed to its uncontrolled popularity. Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Jan 19, 11:17 pm, alex23 wuwe...@gmail.com wrote: ... Hi Daniel Weinreb, Xah wrote: • A Ruby Illustration of Lisp Problems http://xahlee.org/UnixResource_dir/writ/lisp_problems_by_ruby.html Daniel Weinreb wrote: Xah Lee: Elisp is an interesting choice. But without converting the strings to integers, it's not really right. i did post a correction quickly that includes the conversion to string/ num. Here's the full code: (defun read-lines (file) Return a list of lines in FILE. (with-temp-buffer (insert-file-contents file) (split-string (buffer-string) \n t) ) ) (mapcar (lambda (x) (mapcar (lambda (y) (string-to-number y) ) (split-string x ) ) ) (read-lines blob.txt) ) It's interesting that Elisp already has a style of reading in the whole file, but no built-in to convert strings to integers, whereas Common Lisp is the other way around. The statement It is not so mostly because emacs people have drawn themselves into a elitist corner, closing off to the outside world is just a rude ad hominem attack. 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 ) Now, that statement is imprecise, is attacking, needs a lot qualifications. I have literally written about 20 articles each a thousand words or more over the past 3 years that explains many specific cases in painful detail. (e.g. seehttp://xahlee.org/emacs/emacs_essays_index.html ) However, in a one sentence description in this thread's context, calling them “elitist” and “closing off to the outside world”, is to the point. Your claim that this shows something wrong with lists is completely unclear, although if I read your paper (I'll try) I might have some idea what you're getting at More specifically, 2 fundamental problems of lisp i feel this ruby example illustrates well: • the cons impedes many aspects of lists. e.g. difficult to learn, confusing, hard to use, prevent development of coherent list manipulation functions. • nested syntax impedes the functional programing paradigm of function chaining, esp when each function has 2 or more arguments (e.g. map). here's a short summary of the nesting problem: (map f x) ; 1 level of chaining (map g (map f x)) ; 2 levels (map h (map g (map f x))) ; 3 levels compare: x | f | g | h unix pipe x // f // g // h Mathematica h @ g @ f @ x Mathematica x.f.g.h--- various OOP langs, esp Ruby, javascript h g f x --- some functional langs, Haskell, Ocaml The way the above works is that each of f, g, h is a lambda themselves that maps. (that is, something like “(lambda (y) (map f y))”) Note, that any of the f, g, h may be complex pure functions (aka lambda). Because in lisp, each lambda itself will in general have quite a lot nested parens (which cannot be avoided), so this makes any chaining of functions of 2 args, for more than 2 or 3 levels of nesting, unusable for practical coding. One must define the functions separately and just call their names, or use function composition with lambda (which gets complex quickly). One major aspect of this problem is that the scope of vars becomes hard to understand in the deep nested source code. This is worse in elisp, because emacs is dynamically scoped, so you have to avoid using var of same name. More detail here: the section “The Cons Business” at • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html • The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations http://xahlee.org/UnixResource_dir/writ/notations.html 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. Xah ∑http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Tue, 20 Jan 2009 03:39:45 -, Xah Lee xah...@gmail.com wrote: On Jan 19, 4:49 pm, Rhodri James rho...@wildebst.demon.co.uk wrote: On Sun, 18 Jan 2009 08:31:15 -, Xah Lee xah...@gmail.com wrote: 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. I can't imagine why not. consider code produced by corporations, as opposed to with respect to some academic or philsophical logical analysis. Looked in another way, consider if we can compile stat of all existing pyhton code used in real world, you'll find the above style is rarely used. 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. in a logical analysis, each lang fanatics will actively sell certain style of construction, but that's just not the way code in the real world are. Ample examples can be found especially in other cultish lang groups such as lisp, perl, etc. (less of this phenomenon is found in lang like php, javascript, java, C, where the lang simple don't create fancy constructions in the name of improvement or esthetics or weird philosophy in the first place.) Long experience particularly in C suggests that you are entirely wrong. You are conflating simplicity with flexibility; C is a simple language, but it is very syntactically flexible, and programmers not only can but do regularly and with malice aforethought write horribly convoluted code. Sometimes this is out of cunning (dropping through cases in a switch statement, for instance), sometimes because the language is too simple (function dispatch tables can look gruesome if you aren't careful), and sometimes it's because you need a particular sequence of instructions to get the optimiser to Do The Right Thing; regardless, it happens in a large fraction of non-trivial C programs. The above line illustrate well the ad hoc syntax soup nature python is moving into. To a native English speaker, it illustrates entirely the reverse. List comprehension is actually quite a linguistically natural way to express the iterative construction of a list. computer lang is not human lang. In argument based on human lang, you have AppleScript, Perl, which are un-readable or cumbersome to most programers. Even with human lang, if you know linguistics to some extend, you know that natural lang is a complete wortheless mess in every aspect with respect to “design” qualities. Having studied natural languages, I am well aware that the designers of AppleScript didn't study natural languages. If they had, they'd have been a lot more careful in their choice of constructs to map AppleScript onto English less ambiguously. I can't think of a language less like AppleScript than Perl, which is incomprehesible for entirely different reasons. Grouping them together as if they had anything else in common is... eccentric. Computer languages are not human languages, but computer language constructs do attempt to map onto human language constructs to provide some measure of comprehensibility. Where a construct like list comprehension maps very well onto idiomatic English, dismissing it as ad hoc syntax soup is just plain wrong. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Rhodri James wrote: Computer languages are not human languages, but computer language constructs do attempt to map onto human language constructs to provide some measure of comprehensibility. Where a construct like list comprehension maps very well onto idiomatic English, dismissing it as ad hoc syntax soup is just plain wrong. Especially given that Python's comprehensions are taken from Haskell's which are taken from mathematics' set builder notation. Also, care was taken to have a correspondance between comprehension syntax and nested for- and if- statement syntax. Someone recently made a proposal that would break that correspondance and which would be 'ad hoc' and it will surely be rejected. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Xah Lee wrote: consider code produced by corporations, as opposed to with respect to some academic or philsophical logical analysis. Looked in another way, consider if we can compile stat of all existing pyhton code used in real world, you'll find the above style is rarely used. 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. The issue is whether the python code in the real world, by statistics, uses a style such as list comprehension as discussed in this thread. (to simplify the matter: whether code out there uses list comprehension in situations when it can, by what percentage. I claimed it is rare, being borderline esoteric. This can be interpreted as less that 10%) In partcular, the issue, is not about your opinion or joe tech geeker's personal experiences of what they have seen. In newsgroups, every joe geeker makes claims using personal experiences as if that apply for the world. I, of course also based on my claims on personal experience, however, the difference is that my claim is explicitly made in the context of applying to the world. For example, my claim is not about my experiences being such and such. My claim is about such and such is so in the real world. If, now, you claim that it is not so, then perhaps we might have something to argue about. If you can, say, as a example, have a code that crawl the web of all google's own python code at google code for example, and do some simple analysis and report what is the percentage, and if that percentage is more than what i claim, i'll find it very interesting. But if you simply have such code to do such scale of analysis, that's far more interesting by itself than our debate. Similarly, if you can find any evidence, say by some code researcher's reports, that'd be great. At this point, i recall that i have read books on such report. You might try to do research on such books and read up. Long experience particularly in C suggests that you are entirely wrong... Try to study more. I recommend spend less time coding or tech geeking (such as reading blogs, studying languages, or studying computer science ). I recommend taking a course in community college on philosophy, logic, literature, economics. After that, your thinking in coding and all the social issues related to coding, and computing industry, will sharpen by far. Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Jan 20, 7:51 pm, Terry Reedy tjre...@udel.edu wrote: Rhodri James wrote: Computer languages are not human languages, but computer language constructs do attempt to map onto human language constructs to provide some measure of comprehensibility. Where a construct like list comprehension maps very well onto idiomatic English, dismissing it as ad hoc syntax soup is just plain wrong. Especially given that Python's comprehensions are taken from Haskell's which are taken from mathematics' set builder notation. Also, care was taken to have a correspondance between comprehension syntax and nested for- and if- statement syntax. Someone recently made a proposal that would break that correspondance and which would be 'ad hoc' and it will surely be rejected. I suggest you take a course in math history. This is a pratical suggestion. There are community colleges perhaps near you. Register and take a course. If you are in USA, usually they are very cheap because it is funded by taxes. Typically it's 3 hours or so a week, adding homework it might be 10 per week, and last about 3 months. Try it. It's fun. The above won't actually teach you much in htis issue. To get some level of basic knowledge on this, you'll have to have few years on inter-displinary study associated math history, math notations, markup langs, computer syntax, mathematical linguistics related to grammar n syntax... Being a tech geeking hip creature, perhaps you'll never take the above advice. You'd rather immediate read some slashdot or google something and post profusely in online forums. For this, i recommend a few articles of my own: • The Codification of Mathematics http://xahlee.org/cmaci/notation/math_codify.html • The TeX Pestilence http://xahlee.org/cmaci/notation/TeX_pestilence.html • The Problems of Traditional Math Notation http://xahlee.org/cmaci/notation/trad_math_notation.html • A Notation for Plane Geometry http://xahlee.org/cmaci/notation/plane_geometry_notation.html • The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations http://xahlee.org/UnixResource_dir/writ/notations.html of course, i also have very technical and practical book length tutorials on emacs lisp, python, perl, java, javascript/html/css, php, povray. You can find them on my website. Thanks. Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Jan 21, 2:35 pm, Xah Lee xah...@gmail.com wrote: I, of course also based on my claims on personal experience, however, the difference is that my claim is explicitly made in the context of applying to the world. For example, my claim is not about my experiences being such and such. My claim is about such and such is so in the real world. So the claims of people who have personally worked on real world code that contains list comprehensions isn't valid, whereas you who have _no_ such experience have a more genuine understanding of the world? Which is somehow totally unbiased and yet somehow always agrees with your preconceived notions? Talk about Aristotle and his wife's teeth... I recommend taking a course in community college on philosophy, logic, literature, economics. After that, your thinking in coding and all the social issues related to coding, and computing industry, will sharpen by far. Because clearly what the world needs is more of your style of academic understanding over practical, pragmatic knowledge. And arrogant condescension...we sure can't get enough of that. -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Wed, 21 Jan 2009 04:35:22 -, Xah Lee xah...@gmail.com wrote: Xah Lee wrote: Similarly, if you can find any evidence, say by some code researcher's reports, that'd be great. At this point, i recall that i have read books on such report. You might try to do research on such books and read up. Given that you are the one who is attempting proof by repeated assertion, I'd suggest that it is your job to find the evidence to support your claim. I am merely observing that I find your claim highly unlikely. Long experience particularly in C suggests that you are entirely wrong... Try to study more. I recommend spend less time coding or tech geeking (such as reading blogs, studying languages, or studying computer science ). I recommend taking a course in community college on philosophy, logic, literature, economics. After that, your thinking in coding and all the social issues related to coding, and computing industry, will sharpen by far. I recommend spending less time being certain that you are correct without seeking evidence (something the later philosophers seem dreadfully bad at) and more in the application of logical thought. While expanding one's horizons is a good thing (my personal list places more emphasis on the theory and practice of music, theology, literature and democracy, but anything is fair game), expanding one's ego is not. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Sun, 18 Jan 2009 08:31:15 -, Xah Lee xah...@gmail.com wrote: 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. I can't imagine why not. It's clean and clear, after all. If I needed to do the slightly odd processing that it's written to do, the only change I'd make for production code is to wrap the file object in a 'with' statement. • 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. To a native English speaker, it illustrates entirely the reverse. List comprehension is actually quite a linguistically natural way to express the iterative construction of a list. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Jan 19, 4:49 pm, Rhodri James rho...@wildebst.demon.co.uk wrote: On Sun, 18 Jan 2009 08:31:15 -, Xah Lee xah...@gmail.com wrote: 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. I can't imagine why not. consider code produced by corporations, as opposed to with respect to some academic or philsophical logical analysis. Looked in another way, consider if we can compile stat of all existing pyhton code used in real world, you'll find the above style is rarely used. in a logical analysis, each lang fanatics will actively sell certain style of construction, but that's just not the way code in the real world are. Ample examples can be found especially in other cultish lang groups such as lisp, perl, etc. (less of this phenomenon is found in lang like php, javascript, java, C, where the lang simple don't create fancy constructions in the name of improvement or esthetics or weird philosophy in the first place.) • 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. To a native English speaker, it illustrates entirely the reverse. List comprehension is actually quite a linguistically natural way to express the iterative construction of a list. computer lang is not human lang. In argument based on human lang, you have AppleScript, Perl, which are un-readable or cumbersome to most programers. Even with human lang, if you know linguistics to some extend, you know that natural lang is a complete wortheless mess in every aspect with respect to “design” qualities. Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
On Jan 20, 1:39 pm, Xah Lee xah...@gmail.com wrote: consider code produced by corporations, as opposed to with respect to some academic or philsophical logical analysis. Looked in another way, consider if we can compile stat of all existing pyhton code used in real world, you'll find the above style is rarely used. I've worked for several corporations that used Python and at -all- of them the developers were not only aware of list comprehensions, they used them regularly. Same with iterators. Not -one- of them found them to be computer sciency OOP jargons but useful metaphors that made their code more concise without sacrificing readability. Not everything new is crap, y'know. Neither is everything that you fail to understand the first time you're exposed to it. I find it kinda funny that you constantly criticise academic language development when it seems pretty clear from your posts that you've never actually engaged in any practical application-focused development in your life. But as they say: those that can do, those that can't post godawful screeds to their much-hyped-on-usenet vanity blogs... -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
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)) 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
Re: reading file to list
William James schrieb: André Thieme wrote: You make a very strong case that Lisp is very feeble at processing data. I'm almost convinced. I somehow don’t believe you :-) 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]] Just take the program I posted before and replace (.split % \\s) with (re-seq #\d+ %) Now that I was so kind to give you what you asked for, you will probably do the same for me and show me your Ruby code, in which you define a variable that contains the Fibonacci sequence. (def fibs (lazy-cat [0 1] (map + fibs (drop 1 fibs (nth fibs 70) == 190392490709135 One requirement is that when you look at the n'th fib the results up to n must be memoized, so that nothing needs to be calculated again when you ask for a fib between 0 and n. And when you ask for the n+1'th it will start the calculation right from point n. Example: user (time (nth fibs 900)) Elapsed time: 16.898726 msecs user (time (nth fibs 901)) Elapsed time: 0.268603 msecs André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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
Re: reading file to list
Xah Lee wrote: comp.lang.lisp,comp.lang.scheme,comp.lang.functional,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 18)) 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)] HTH Tino smime.p7s Description: S/MIME Cryptographic Signature -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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/writ/lisp_problems_by_ruby.html Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Tino Wildenhain wrote: Xah Lee wrote: comp.lang.lisp,comp.lang.scheme,comp.lang.functional,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 18)) 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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/writ/lisp_problems_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/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
MRAB wrote: Tino Wildenhain wrote: Xah Lee wrote: comp.lang.lisp,comp.lang.scheme,comp.lang.functional,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 18)) 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: Actually I read: 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. So I felt that requirement was dropped, but otherwise, you are right :-) [[int(x) for x in line.split()] for line in open(blob.txt)] Still only 1 line, though. Yep. Regards Tino smime.p7s Description: S/MIME Cryptographic Signature -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Xah Lee schrieb: 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)) 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 18) And then read it back into the program with: (map read-string (line-seq (reader blob.txt))) André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Xah Lee wrote: • A Ruby Illustration of Lisp Problems http://xahlee.org/UnixResource_dir/writ/lisp_problems_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 fucked 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/writ/lisp_problems.html Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
Xah Lee schrieb: Xah Lee wrote: • A Ruby Illustration of Lisp Problems http://xahlee.org/UnixResource_dir/writ/lisp_problems_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 fucked 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/writ/lisp_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/scicache/184/scimakelatex.7076.Xah+Lee.html Another crap posting of you. But a random person might be impressed. André -- -- http://mail.python.org/mailman/listinfo/python-list
Re: reading file to list
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/writ/lisp_problems_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/writ/lisp_problems.html Xah ∑ http://xahlee.org/ ☄ -- http://mail.python.org/mailman/listinfo/python-list