Re: reading file to list
Xah Lee
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/
☄
Tino Wildenhain
> 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
Xah Lee
> 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/
☄
MRAB
> Xah Lee wrote:
>> comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.lang.ruby
>>
>>
> ...
>> 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))
>
>>
>> far verbose than ruby or say perl (which is 1 or 2 lines. (python
>> would be 3 or 5)).
>
>
> [line.strip().split() for line in file("blob.txt")]
>
[[int(x) for x in line.split()] for line in open("blob.txt")]
Still only 1 line, though.
Xah Lee
> 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/
☄
Tino Wildenhain
> Tino Wildenhain wrote:
>> Xah Lee wrote:
>>> comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.python,comp.lang.ruby
>>>
>>>
>> ...
>>> 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))
>>
>>>
>>> far verbose than ruby or say perl (which is 1 or 2 lines. (python
>>> would be 3 or 5)).
>>
>>
>> [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
André Thieme
> 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))
>
>
> 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é
--
Xah Lee
> • 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/
☄
André Thieme
> 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é
--
Xah Lee
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/
☄
Xah Lee
> > [[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/
☄
William James
> Xah Lee schrieb:
> > comp.lang.lisp,comp.lang.scheme,comp.lang.functional,comp.lang.pytho
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]]
André Thieme
> 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é
--
Rhodri James
> 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
Xah Lee
wrote:
> On Sun, 18 Jan 2009 08:31:15 -0000, 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/
☄
alex23
> 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...
Xah Lee
...
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.
☄
Rhodri James
> On Jan 19, 4:49 pm, "Rhodri James" <rho...@wildebst.demon.co.uk>
> wrote:
>> On Sun, 18 Jan 2009 08:31:15 -0000, 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.
Terry Reedy
> 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
Xah Lee
> > 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/
☄
Xah Lee
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/
☄
alex23
> 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.
Rhodri James
> 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.
Xah Lee
> 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/
☄
Lars Behrens
> 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
> As a non-native speaker and non-academic, I don't understand the "fittine
"fitting", I meant. Sorry ^^
--
Cheerz Lars
Steve Holden
> 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 )
>
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/
Rhodri James
wrote:
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
> 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*
Xah Lee
> *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/
☄
William James
> (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"))
nick_keigh...@hotmail.com
> 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
> )
> )
>
> (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
> 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:
nick_keigh...@hotmail.com
> 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>
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_keigh...@hotmail.com
<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?
Xah Lee
> 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.
------------------------------
compare:
☄
Xah Lee
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
;; there's a fresh completion window with a live buffer,
;; and this command is repeated, scroll that window.
(with-current-buffer (window-buffer window)
(if (pos-visible-in-window-p (point-max) window)
(set-window-start window (point-min))
(save-selected-window
(select-window window)
(scroll-up))))
;; Do completion.
(let* ((end (point))
(beg (with-syntax-table emacs-lisp-mode-syntax-table
(save-excursion
(backward-sexp 1)
(while (= (char-syntax (following-char)) ?\')
(forward-char 1))
(point))))
(pattern (buffer-substring-no-properties beg end))
(predicate
(or predicate
(save-excursion
(goto-char beg)
(if (not (eq (char-before) ?\())
(lambda (sym) ;why not just nil ? -sm
(or (boundp sym) (fboundp sym)
(symbol-plist sym)))
;; Looks like a funcall position. Let's double check.
(if (condition-case nil
(progn (up-list -2) (forward-char 1)
(eq (char-after) ?\())
(error nil))
;; If the first element of the parent list is an open
;; parenthesis we are probably not in a funcall position.
;; Maybe a `let' varlist or something.
nil
;; Else, we assume that a function name is expected.
'fboundp)))))
(completion (try-completion pattern obarray predicate)))
(cond ((eq completion t))
((null completion)
(message "Can't find completion for \"%s\"" pattern)
(ding))
((not (string= pattern completion))
(delete-region beg end)
(insert completion)
;; Don't leave around a completions buffer that's out of date.
(let ((win (get-buffer-window "*Completions*" 0)))
(if win (with-selected-window win (bury-buffer)))))
(t
(let ((minibuf-is-in-use
(eq (minibuffer-window) (selected-window))))
(unless minibuf-is-in-use
(message "Making completion list..."))
(let ((list (all-completions pattern obarray predicate)))
(setq list (sort list 'string<))
(or (eq predicate 'fboundp)
(let (new)
(while list
(setq new (cons (if (fboundp (intern (car list)))
(list (car list) " <f>")
(car list))
new))
(setq list (cdr list)))
(setq list (nreverse new))))
(if (> (length list) 1)
(with-output-to-temp-buffer "*Completions*"
(display-completion-list list pattern))
;; Don't leave around a completions buffer that's
;; out of date.
(let ((win (get-buffer-window "*Completions*" 0)))
(if win (with-selected-window win (bury-buffer))))))
(unless minibuf-is-in-use
(message "Making completion list...%s" "done")))))))))
Xah
∑ http://xahlee.org/
☄