When is Xah going to ease up on Emacs...

....and start shredding ASDF?

kt

ps. yep, and it's the classic: ASDF loading in the wrong order because
McCLIM screwed something up.

pps. Add a new one, cuz even serial cannot help cross-system. k

--

$$$$$: http://www.theoryyalgebra.com/
Cells: http://common-lisp.net/project/cells/
BSlog: http://smuglispweeny.blogspot.com/

On Wed, 13 Aug 2008 13:12:28 -0400, <kentilton@gmail.com> wrote:
> When is Xah going to ease up on Emacs...

When I get my concession license for the Hades icerink.

--
One of the strokes of genius from McCarthy
was making lists the center of the language - kt
** Posted from http://www.teranews.com **

On Aug 13, 10:12 am, Kenny <kentil...@gmail.com> wrote:
> When is Xah going to ease up on Emacs...
> ...and start shredding ASDF?
>
> kt
>
> ps. yep, and it's the classic: ASDF loading in the wrong order because
> McCLIM screwed something up.
>
> pps. Add a new one, cuz even serial cannot help cross-system. k

umm... should i increase my lisp activity here?

--------------------

Fundamental Problems of Lisp

Xah Lee, 2008-07

Since i'm writing... n i wrote a lot in the past on diverse issues
scattered in various essays... i'll sum up some fundamental problems
of lisp:

• Lisp relies on a regular nested syntax. However, the lisp syntax has
several irregularities, that reduces such syntax's power and confuses
the language semantics. (i.e. those «' # ; ` ,» chars.) (and whenever
i tried to get some technical answer about this to clarify at least my
own understanding, protective lispers muck and obfuscate the truth.
(its likely that few lispers actually completely understand all of
lisp's syntactical irregularities.))

• Lisp's irregular syntax those «' # ; ` ,» things, are practically
confusing and made the lang less powerful. i.e. in elisp, there's no
form of comment in matching delimiters (and consequently no nested
comment). The reliance on EOL chars as part of the syntax semantics is
one of the major detriment of the power of pure nested syntax.

• Lisp relies on a regular nested syntax. Because of such regularity
of the syntax, it allows transformation of the source code by a simple
lexical scan. This has powerful ramification. (practically, lispers
realized just one: the lisp macros) For example, since the syntax is
regular, one could easily have alternative, easier to read syntaxes as
a layer. (the concept is somewhat known in early lisp as M-expression)
Mathematica took this advantage (probably independent of lisp's
influence), so that you really have easy to read syntax, yet fully
retain the regular form advantages. In lisp history, such layer been
done and tried here and there in various forms or langs ( CGOL↗,
Dylan↗), but never caught on due to largely social happenings. Partof
these reasons are political. (thanks to, in part, sensitive and
ignorant lispers here that stops proper discussion of it.)

• One of the advantage of pure fully functional syntax is that a
programer should never need to format his source code (i.e. pressing
tabs, returns) in coding, and save the hundreds hours of labor,
guides, tutorials, advices, publications, editor tools, on what's
known as “coding style convention�, because the editor can reformat
the source code on the fly based on a simple lexical scan. This is
done in Mathematica version 3 (~1996). In coding elisp, i'm pained to
no ends by the manual process of formatting lisp code. The lisp
community, established a particular way of formatting lisp code as
exhibited in emacs's lisp modes and written guides of conventions. The
recognization of such convention further erode any possibility and
awareness of automatic, uniform, universal, formatting. (e.g. the
uniform and universal part of advantage is exhibited by Python)

• Lisp relies on a regular nested syntax. One of the power of such
pure syntax is that you could build up layers on top of it, so that
the source code can function as markup of conventional mathematical
notations (i.e. MathML) and or as a word-processing-like file that can
contain structures, images (e.g. Microsoft Office Open XML↗), yet lose
practical nothing. This is done in Mathematica in ~1996 with release
of Mathematica version 3. (e.g. think of XML, its uniform nested
syntax, its diverse use as a markup lang, then, some people are adding
computational semantics to it now (i.e. a computer language with
syntax of xml. e.g. O:XML↗). You can think of Mathematica going the
other way, by starting with a computer lang with a regular nested
syntax, then add new but inert keywords to it with markup semantics.
The compiler will just treat these inert keywords like comment syntax
when doing computation. When the source code is read by a editor, the
editor takes the markup keywords for structural or stylitic
representation, with title, chapter heading, tables, images,
animations, hyperlinks, typeset math expression (e.g. think of
MathML↗) etc. The non-marked-up keywords are shown as one-dimentional
textual source code just like source code is normally shown is most
languages.)

Further readings:

* The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations
* The Harm of Hard-wrapping Lines
* A Text Editor Feature: Syntax Tree Walk
* A Simple Lisp Code Formatter

The above are some of the damages lispers has done to themselfs, with
respect to its nested functional syntax. The other major one is the
cons business.

• Lisp at core is based on functional programing on lists. This is
comparatively a powerful paradigm. However, for historical reasons,
lisp's list is based on the hardware concept of “cons� cell.. From a
mathematical point of view, what this means is that lisp's lists is
limited to a max of 2 elements. If you want a longer list, you must
nest it and interpret it in a special way. (i.e. effectively creating
a mini-protocol of nesting lists, known as proper lists.) The cons
fundamentally crippled the development of list processing.

Lisp being historically based the cons for like 2 or 3 decades. The
cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp
langs, is thus not something that can be easily fixed. Quite
unfortunate. However, this situation could be improved. (by, for
example, emphasizing only higher-level list manipulation functions and
develope a convention that minimize or even forbid the use of cons/car/
cdr) But, whenever i discuss this, you can see that the lisper slaves
here, their mentality, prevents any possible improvement. (most do not
even understand what's the issue. (in general, this is because,
lispers usually do not have serious experience or investment in other
functional langs, such as Mathematica, Haskell, etc.))

One of the myth that is quickly embedded into budding lispers, is that
cons are powerful. Powerful my ass. It is powerful in the sense any
assembly lang is powerful. Lisp's cons is perhaps the greatest fuck up
in the history of computer languages.

-----------------------

html version at:
http://xahlee.org/UnixResource_dir/w..._problems.html

Xah
∑ http://xahlee.org/

☄

Some entity, AKA "xahlee@gmail.com" <xahlee@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)


> umm... should i increase my lisp activity here?
YES!
But only after you succeeded in the worldwide banning of parenteses to exist on standard
keyboard layouts.

Cor

--
Mijn Tools zijn zo modern dat ze allemaal eindigen op 'saurus'
(defvar My-Computer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
SPAM DELENDA EST http://www.clsnet.nl/mail.php
1st Law of surviving a gunfight : Have a gun !

xahlee@gmail.com wrote:

> ¡E Lisp at core is based on functional programing on lists. This is
> comparatively a powerful paradigm. However, for historical reasons,
> lisp's list is based on the hardware concept of ¡§cons¡¨ cell. From a
> mathematical point of view, what this means is that lisp's lists is
> limited to a max of 2 elements. If you want a longer list, you must
> nest it and interpret it in a special way. (i.e. effectively creating
> a mini-protocol of nesting lists, known as proper lists.) The cons
> fundamentally crippled the development of list processing.

If you don't like lists, Common Lisp has arrays and hashmaps, too.

> Lisp being historically based the cons for like 2 or 3 decades. The
> cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp
> langs, is thus not something that can be easily fixed. Quite
> unfortunate. However, this situation could be improved. (by, for
> example, emphasizing only higher-level list manipulation functions and
> develope a convention that minimize or even forbid the use of cons/car/
> cdr) But, whenever i discuss this, you can see that the lisper slaves
> here, their mentality, prevents any possible improvement. (most do not
> even understand what's the issue. (in general, this is because,
> lispers usually do not have serious experience or investment in other
> functional langs, such as Mathematica, Haskell, etc.))

I like the CONS concept. Even in functional languages like Haskell it is
popular, e.g. when matching in the form of (x:xs), which is the same like
car/cdr in Lisp.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On Aug 15, 8:11 pm, Frank Buss <f...@frank-buss.de> wrote:
> xah...@gmail.com wrote:
> > ‧ Lisp at core is based on functional programing on lists. Thisis
> > comparatively a powerful paradigm. However, for historical reasons,
> > lisp's list is based on the hardware concept of “cons� cell. From a
> > mathematical point of view, what this means is that lisp's lists is
> > limited to a max of 2 elements. If you want a longer list, you must
> > nest it and interpret it in a special way. (i.e. effectively creating
> > a mini-protocol of nesting lists, known as proper lists.) The cons
> > fundamentally crippled the development of list processing.
>
> If you don't like lists, Common Lisp has arrays and hashmaps, too.

LOL, i hope i dont have to explain this again.

let me explain it this way.

Suppose there's a lang called gisp. In gisp, there's fons. Fons are
just like cons except it has 3 cells, and you have 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 and car, cbr, cdr, or any
one of the caar, cdar, cbbar, cdbbar, etc. You got annoyed by this to
no ends.

You as a critic, complains that fons is bad. But then some brainless
gisp fan retort by saying: “If you don't like fons, gist has cons,
too.�.

You see, if you don't see it yet, that by “having something too�, does
not solve the problem of bad polution. Sure, you can use just cons in
gist, but every lib or other's code you encounter, there's a invasion
of fons with its cbbar, cdbbar, cbbbr.

> > Lisp being historically based the cons for like 2 or 3 decades. The
> > cons (and cdr, car, caadar etc) are fundamentally rooted in the lisp
> > langs, is thus not something that can be easily fixed. Quite
> > unfortunate. However, this situation could be improved. (by, for
> > example, emphasizing only higher-level list manipulation functions and
> > develope a convention that minimize or even forbid the use of cons/car/
> > cdr) But, whenever i discuss this, you can see that the lisper slaves
> > here, their mentality, prevents any possible improvement. (most do not
> > even understand what's the issue. (in general, this is because,
> > lispers usually do not have serious experience or investment in other
> > functional langs, such as Mathematica, Haskell, etc.))
>
> I like the CONS concept. Even in functional languages like Haskell it is
> popular, e.g. when matching in the form of (x:xs), which is the same like
> car/cdr in Lisp.

I tried to explain the cons problem to lispers but usually they retort
something like the above. In the past i'd think they are just to fuck
with me. But due to my new learned experience of conversational styled
post, i find that the fact is that they are actually just stupid,
ingorant, or just too lack of critical thinking abilities.

Let me try to explain this calmly.

> I like the CONS concept. Even in functional languages like Haskell it is
> popular,

What you mean by “CONS concept�? can you clarify?

> e.g. when matching in the form of (x:xs), which is the same like
> car/cdr in Lisp.

When you say that this is like lisp's car/cdr, do you mean that any
language with a list datatype and has a first and rest function, is
considered having lisp's cons?

Answer, and i'll reply calmly.

Xah
∑ http://xahlee.org/

☄

OK, your question i've seen so often now for the first time i've added
it as a FAQ here:

http://xahlee.org/UnixResource_dir/w..._problems.html

---------------------------

Frequently Asked Questions

Q: If you don't like lists, Common Lisp has arrays and hashmaps, too.

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 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 and car, cbr,
cdr, or any one of the caar, cdar, cbbar, cdbbar, etc. You got annoyed
by this. You as a critic, complains that fons is bad. But then some
gisp fan retort by saying: “If you don't like fons, gisp has cons,
too.�.

You see, by “having something too�, does not solve the problem of bad
polution. 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 cbbar,
cdbbar, cbbbr. The problem created by fons cannot be solved by “having
cons too�.



Q: I like the CONS concept. Even in functional languages like Haskell
it is popular, e.g. when matching in the form of (x:xs), which is the
same like car/cdr in Lisp.

Languages that has a list datatype and First, Rest functions does not
mean it has lisp's cons problem.

One part of the cons problem in lisp is that it forces programer to
think of list in a low-level nested of 2-item construction, with
explicit functions like “cons�, “car�, “cdr�, “caar�, “cadr�, “cdar�,
“cddr�, “caaar�, “caadr� etc.

In other langs, the programer is not forced to think of nested 2-
items.

The other problem with lisp's cons, is that it hinders any development
of tree data structure. For example, one might write a function that
extracts the leafs of a tree. But due to lisp's list made of cons,
there is a different interpretation of leaf. Similarly, binary tree in
lisp can be implemented either using cons natively, or use proper
list. The overall effect of the cons is that it prevents lisp to have
a uniform view of tree structure so that development of functions that
works on trees are inconsistent, few, or otherwise hampered.

Xah
∑ http://xahlee.org/

☄

xahlee@gmail.com wrote:

> Q: I like the CONS concept. Even in functional languages like Haskell
> it is popular, e.g. when matching in the form of (x:xs), which is the
> same like car/cdr in Lisp.
>
> Languages that has a list datatype and First, Rest functions does not
> mean it has lisp's cons problem.
>
> One part of the cons problem in lisp is that it forces programer to
> think of list in a low-level nested of 2-item construction, with
> explicit functions like ´cons¡, ´car¡, ´cdr¡, ´caar¡, ´cadr¡, ´cdar¡,
> ´cddr¡, ´caaar¡, ´caadr¡ etc.
>
> In other langs, the programer is not forced to think of nested 2-
> items.

This is true for Lisp, too. If you write your own programs, you don't have
to use cons. And many Lisp libraries have more high level interfaces than
cons, e.g. like the built-in sort function, which requires a sequence, not
a list, or object oriented CLOS libraries.

> The other problem with lisp's cons, is that it hinders any development
> of tree data structure. For example, one might write a function that
> extracts the leafs of a tree. But due to lisp's list made of cons,
> there is a different interpretation of leaf.

I don't understand you. E.g. I would write a tree like this:

(defparameter *t*
'(("languages"
("Lisp")
("Java")
("Haskell"))
("concepts"
("tree"
("binary tree")
("general tree"))
("list"))))

which can be processed with a program like this:

(defun spaces (count)
(with-output-to-string (s)
(loop repeat count do (princ #\Space s))))

(defun print-tree (tree &optional (ident 0))
(loop for (content . children) in tree do
(format t "~a~a~%" (spaces ident) content)
(print-tree children (+ ident 2))))

(print-tree *t*) shows the tree without the parantheses and double quotes:

languages
Lisp
Java
Haskell
concepts
tree
binary tree
general tree
list

There is only one interpretation of a leaf: It is a CONS with cdr=nil.

With this concept you can build nice algorithms for extracting leafs,
merging trees etc. In languages like Haskell, some programs might be more
difficult, because you can't mix different types in a tree and if you have
a tree of newsgroups, you can't use the same algorithm for a tree of
numbers within the same program. C++ has templates to solve the latter
problem, but the syntax is complicated and ugly.

> Similarly, binary tree in
> lisp can be implemented either using cons natively, or use proper
> list. The overall effect of the cons is that it prevents lisp to have
> a uniform view of tree structure so that development of functions that
> works on trees are inconsistent, few, or otherwise hampered.

Yes, that's the drawback in Lisp: There are many ways to implement
something. But I would assume a well written library, which works on trees,
has abstracted low-level access to lists with functions, e.g. get-children,
leafp etc., so you just have to implement the low-level functions and the
library works.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss wrote:
«There is only one interpretation of a leaf: It is a CONS with
cdr=nil.»

Not true.

Recently there's a thread exactly on this. See
http://groups.google.com/group/comp....61883cabde5a84

I've given a detailed answer. See below:

someone wrote:
«
(setf bin-tree '(4 (2 1 3) (6 5 7)))

Thus in my view the only fringe nodes (leaves) are 1, 3, 5, and 7.
»

Yes, you are right.

also note, when in a language where there's isomorphism between the
syntax and the nested list, there's a concept of head.

For example, in pseudo lisp:

(list (list 1 3) (list 5 7))

In this list, the 1,3,5,7 are leafs. Each having index {1,1}, {1,2},
{2,1}, {2,2}.

Now, the three appearances of “list�, are non-leaf nodes inthe tree,
having indexes of: {0}, {1,0}, {2,0}. These positions are called Head
in Mathematica, and the notion of head also appear in lisp.

Now, consider this pseudo lisp: (4 (2 1 3) (6 5 7))

which is closer to what you gave above. Now, the element at index {0}
is 4, and at {1,0} is 2, and at {2,0} is 6.

The whole expression itself, is still a tree or a nested list. In this
way, we can see that there is a isomorphism between the textual
representation of a tree, and what is actually considered a list
datatype in the lisp-like language.

So, suppose you invented a lisp language, so that there's no cons, but
the symbol “list� represent a list datatype (the implementation of the
language may actually just be linked list as cons). So, in this
language, the expression

(list (list 1 3) (list 5 7))

would represent a list datatype. However, the expression

(4 (2 1 3) (6 5 7))

would not be a list datatype, however, the expression's structure is
identical to the previous one, and still a tree. In this language,
when the head of a expression does not have a valid definition, such
as being a integer, it is simply left unevaluated.

So, in this lang, both

(list (list 1 3) (list 5 7)) and (4 (2 1 3) (6 5 7))

are valid expressions, and of identical structure. The expression
itself represent a tree. The 2 expression can be easily transformed
into each other, by simply doing a replacement of the atom “list� to
one of integer, or vice versa. (e.g. replacing by pattern matching or
actually apply a function to the head positions)

Now, the thing about languages with a pure nested syntax is that, the
head itself can be a nested expression. For example, you can have

((f x) 1 2 3)

So, when you have a expression such as

(x (y 1 3) (z 5 7))

The indexes at {0}, {1,0}, {2,0}, i.e. the x, y, z, needs not to be
atoms themselves. They can be arbitrary expressions (tree).

So this means, in this language the head, or non-leaf nodes of a tree,
can hold data, not just the leafs.

In most lang that supports nested list, such as perl, php, python,
only the leaf nodes holds data. But as you can see the above, in this
lang with regular nested syntax, not only leaf nodes can hold data,
but any node, including non-leaf nodes (heads), can hold arbitrarily
nested data.

As a illustration to intermediat, in XML, the none-leaf nodes can hold
a limited amount of data, called its attributes.

actually, lang such as perl, php, python, javascript, you can actually
have a nested list where the non-leaf nodes also holds arbitrary
data. All you have to do, is to consider that the first element of a
list as the non-leaf nodes (i.e. lisp's “head�).

In langs such as perl etc, assuming 1st element of list as non-leaf
node is not a problem. But in lang with a purely nested syntax, by
assuming the 1st element of list as non-leaf node, i think it
necessarily introduces a more complex model of interpretation if you
still want a isomorphism between the syntax, tree, and list datatype.

--------------------------

Now, in lisp, because of the cons, combined with the fact that its
syntax is irregular, truely, fucked up all the beauty and power of
list processing.

The problem of the cons business is well known. For example, your
surprise at the various definition of leaf is just one Frequent
puzzle. The other thing about its irregular syntax, such as

'(1 2 3)
(quote (1 2 3))
(list 1 2 3)

adds more complexity to the cons problem. For example, if you read
again the above exposition about the isomorphism between the purely
nested uniform syntax, tree, and list datatype, and try to apply it to
Common Lisp, Emacs Lisp, or Scheme Lisp, you'll find all sort of
problems, and really see how lisp is crippled, in the sense that it
could have been far more consistent, simpler, powerful.

The above pseudo lisp lang explanation is based on my knowledge of
Mathematica. i.e. it is basically how Mathematica is.

Further readings:

• Trees
http://xahlee.org/tree/tree.html

• “The Concepts and Confusions of Prefix, Infix, Postfix and Fully
Functional Notations�
http://xahlee.org/UnixResource_dir/writ/notations.html

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

Xah
∑ http://xahlee.org/

☄

On Aug 16, 12:26*pm, "xah...@gmail.com" <xah...@gmail.com> wrote:
> You as a critic, complains that fons is bad. But then some brainless
> gisp fan retort by saying: “If you don't like fons, gist has cons,
> too.”.

I'm afraid

cons / array

is in no way analagous to

fons / cons

Besides, in other languages I find myself generally using one of
x[0], x[i], or x[x.length]

These methods of list usage are possible with cons-based lists too,
without using *any* car's or cdr's!

(nth 0 x), (nth i x), (nth (length x) x)

although generally, you could use...

(first x) (nth i x) (last x)

Your car and cdr problems solved. God I'm a genius.