...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, <·········@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 <·········@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. Part of
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/writ/lisp_problems.html
Xah
∑ http://xahlee.org/
☄
Some entity, AKA ·······@gmail.com" <······@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 !
······@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, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Aug 15, 8:11 pm, Frank Buss <····@frank-buss.de> wrote:
> ······@gmail.com wrote:
> > ‧ 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.
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/
☄
On Aug 16, 12:26 pm, ·······@gmail.com" <······@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.
On Aug 23, 6:40 am, Ali <·············@gmail.com> wrote:
> On Aug 16, 12:26 pm, ·······@gmail.com" <······@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)
Careful. LAST is the last CONS of a list.
Cheers
--
Marco
> Your car and cdr problems solved. God I'm a genius.
> Careful. LAST is the last CONS of a list.
Oh dammit, thanks.
Even so, it is still not true that lisp
"forces programer to think of list in a low-level nested of 2-item
construction"
Because one can still access the elements directly through these
means, just as might be done in other languages.
(defun end (x)
(first (last x)))
(first x) (nth i x) (end x)
Ali wrote:
>>Careful. LAST is the last CONS of a list.
>
>
> Oh dammit, thanks.
>
> Even so, it is still not true that lisp
>
> "forces programer to think of list in a low-level nested of 2-item
> construction"
Good luck to anyone trying to program lisp without a profound
understanding of cons. Lotsa times one can get by without that
understanding but lotsa aint enough to write software.
kt
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/writ/lisp_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/
☄
······@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, ··@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.lang.lisp/browse_frm/thread/561883cabde5a84
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 in the 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/writ/lisp_problems.html
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> 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.lang.lisp/browse_frm/thread/561883cabde5a84
>
> 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.
> �
You are right, there are many concepts how to build trees with lists. If
you want just content in leafes and not nodes with children, there are more
compact representations.
> 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.
This is still a binary tree? I don't understand the syntax {1,0}.
> (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.
You can achieve this in Common Lisp just with a quote in front of the list.
Not evaluating something which is not defined would not be very Lisp-like.
With Common Lisp you write what you mean. This prevents error like if you
have a spelling error and instead of an error, that a function is not
defined, with your concept it would silently ignored.
> 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)
I don't see how it can be transformed. How does the transformer know that
the first "list" has to be replaced by "4"?
> 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.
I don't understand this. With my proposal a Lisp list can do this, too. The
only limitation would be that a node can't hold a list as data, but this
could be solved by wrapping lists in a defstruct, or just adding one more
layer of lists for each node, or create your tree class library with CLOS,
if you really need it.
> 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.
In Common Lisp not every list has to be evaluated, so I don't see a problem
doing the same in Lisp.
> 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.
Maybe the reason that I don't see the problem is that I know Common Lisp
and for me it looks logical. The syntax is very consise: If you evaluate a
list, the first element is always the function name and the rest are the
arguments. If you don't want to evaluate it, you quote it. Maybe Common
Lisp is not as orthogonal as it could be, e.g. you can't overload the
"+"-function to work with e.g. own defined CLOS classes (ok, you can, but
you have to shadow the system "+", and do some typecase switching in your
"+" function), but your (list 1 2 3) example is just the function "list",
called with 1 2 3. I don't see any irregularities with this.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Hi Frank,
Frank wrote:
> > 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.
>
> This is still a binary tree? I don't understand the syntax {1,0}.
See the 5 articles on trees here:
• Trees
http://xahlee.org/tree/tree.html
btw, just in the past 2 weeks there has been a thread with now over
100 messages. You can group.google.com it with string “Xah on Lisp”.
The thread basically cover everything we are discussing here. If you
don't care to wade thru the thread, i have actually culled all the
parts in these article:
• “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/writ/lisp_problems.html
btw, do you know any other functional language well? it would greatly
help if you know at least one other modern functional lang well. e.g.
haskell, ocmal, erlang, etc. It can greatly aid in your views to lisp.
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> The thread basically cover everything we are discussing here. If you
> don't care to wade thru the thread, i have actually culled all the
> parts in these article:
>
> �E ��The Concepts and Confusions of Prefix, Infix, Postfix and Fully
> Functional Notations��
> http://xahlee.org/UnixResource_dir/writ/notations.html
I don't see how this is related to the problems with trees you wrote about.
Some points from your article:
| (1) Some 99% of programers are not used to the nested parenthesis syntax.
| This is a practical problem. On this aspect along, lisp's syntax can be
| considered a problem.
|
| (2) Arguably, the pure nested syntax is not natural for human to read. Long
| time lispers may disagree on this point.
I disagree on this points :-)
| (3) Most importantly, a pure nested syntax discourages frequent or advanced
| use of function sequencing or compositions. This aspect is the most
| devastating.
If you like, you can write your own compose funcion in Common Lisp to make
it easier to write and read long compositions:
http://www.bookshelf.jp/texi/onlisp/onlisp_6.html
But it is not as nice as e.g. in Haskell.
> �E Fundamental Problems of Lisp
> http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
Same problem: You don't like some constructs like ",@" etc. in Lisp. These
are just abbreviation, you can write anything in the usual prefix form.
E.g. this macro:
(defmacro one (x) `(1+ ,x))
can be written like this:
(defmacro one (x) (list (quote 1+) x))
So you are right, there are irregularities in the syntax, but it's just for
lazy programmers :-)
> btw, do you know any other functional language well? it would greatly
> help if you know at least one other modern functional lang well. e.g.
> haskell, ocmal, erlang, etc. It can greatly aid in your views to lisp.
I know a bit of Haskell, e.g. I've written some small demo programs to
understand the language, like this one:
http://www.frank-buss.de/haskell/OlympicRings2.hs.txt
which produces this image:
http://www.frank-buss.de/haskell/OlympicRings2.png
But currently I'm using JavaScript a bit more, which is a nice prototype
based language (I don't understand why they moved toward Java classes with
the new ActionScript 3 in Adobe Flash, but fortunately nearly every browser
still knows the real prototype based JavaScript, and there are open source
ECMA Script interpreters). It can be considered as a functional language,
because it has closures and supports higher-order functions. My latest
JavaScript program is an interpreter for the language COW:
http://www.frank-buss.de/cow.html
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Dear Frank,
On Aug 24, 12:18 am, Frank Buss <····@frank-buss.de> wrote:
> > ‧ Fundamental Problems of Lisp
> > http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
>
> Same problem: You don't like some constructs like ",@" etc. in Lisp. These
> are just abbreviation, you can write anything in the usual prefix form.
> E.g. this macro:
>
> (defmacro one (x) `(1+ ,x))
>
> can be written like this:
>
> (defmacro one (x) (list (quote 1+) x))
>
> So you are right, there are irregularities in the syntax, but it's just for
> lazy programmers :-)
the issue is about design consistency, is not about whether sugar
syntax are convenient.
For example, this sugar syntax:
“'(1 2 3)”
for
“(quote (1 2 3))”
can be designed alternatively like this:
“(' (1 2 3))”
which keeps lisp's regular form (f args).
This issue is emphasize in the article, and as well as a FAQ item in
the article. Please read the article carefully!
-------------------
Frank wrote:
«
I know a bit of Haskell, e.g. I've written some small demo programs
to
understand the language, like this one:
http://www.frank-buss.de/haskell/OlympicRings2.hs.txt
which produces this image:
http://www.frank-buss.de/haskell/OlympicRings2.png
»
Nice. Btw, what graphics system you used?
i recall now you are the one who did this algorithmic artwork:
http://www.frank-buss.de/lisp/functional.html
What graphics systems did you use on these? I mean, in Mathematica,
the graphics system is build in, where the lang has geometry
primitives and the editor can display them.
In perl, python, and other lang, i can produce graphics by generating
string that is basically the povray file. Then use povray to display
them.
but i'm interested in other such systems... could you give some
detail?
thanks.
(i tried to access
http://www.ecs.soton.ac.uk/%7Eph/papers/funcgeo2.pdf
but it seems down? or extremely slow
)
PS also, a good priciple in web design is to have a link to the index,
or some nav bar, else each of the page or article is a island...
Xah
∑ http://xahlee.org/
☄
Some entity, AKA ·······@gmail.com" <······@gmail.com>,
wrote this mindboggling stuff:
(selectively-snipped-or-not-p)
>> So you are right, there are irregularities in the syntax, but it's just for
>> lazy programmers :-)
>
> the issue is about design consistency, is not about whether sugar
> syntax are convenient.
If you don't like it, rewrite the stuff, load it in your own
lisp-image as xahs-facistoid-syntax-reader.lisp and use it.
But do never ever come complaining here again, 'ya hear.
On the other hand you might try to bribe de whole ANSI committee to
change the specification, this might have a chance since it is rumoured
that something similar was done to ISO.
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 armed conflict : Have a gun !
······@gmail.com wrote:
> the issue is about design consistency, is not about whether sugar
> syntax are convenient.
>
> For example, this sugar syntax:
> �'(1 2 3)�
> for
> �(quote (1 2 3))�
>
> can be designed alternatively like this:
> �(' (1 2 3))�
>
> which keeps lisp's regular form (f args).
But this wouldn't be very sweet syntactic sugar. Maybe you should try to
use Lisp for a larger project yourself to see if it is usable. I think the
way how ' is defined helps to write and read Lisp code. But you can change
the Lisp reader, if you don't like it and create your own syntax.
> Frank wrote:
> �
> I know a bit of Haskell, e.g. I've written some small demo programs
> to
> understand the language, like this one:
> http://www.frank-buss.de/haskell/OlympicRings2.hs.txt
> which produces this image:
> http://www.frank-buss.de/haskell/OlympicRings2.png
> �
>
> Nice. Btw, what graphics system you used?
I created my own TGA image write functions. It is included in the 129 lines
source code.
> i recall now you are the one who did this algorithmic artwork:
>
> http://www.frank-buss.de/lisp/functional.html
>
> What graphics systems did you use on these?
Postscript. See the end of the webpage.
> I mean, in Mathematica,
> the graphics system is build in, where the lang has geometry
> primitives and the editor can display them.
>
> In perl, python, and other lang, i can produce graphics by generating
> string that is basically the povray file. Then use povray to display
> them.
>
> but i'm interested in other such systems... could you give some
> detail?
For this page:
http://www.frank-buss.de/lisp/texture.html
I wrote a simple system, called CL-Canvas. It is just a canves, where I can
draw on, even interactivly from the REPL. But it works on Windows, only.
Nowadays I would use the SDL packages of the Application Builder project (
http://www.lispbuilder.org ), which I initiated some time ago.
> (i tried to access
> http://www.ecs.soton.ac.uk/%7Eph/papers/funcgeo2.pdf
> but it seems down? or extremely slow
Works for me, but I'm using Foxit Reader as an external program for reading
PDF documents. If you use Adobe PDF Reader, sometimes it tries to load the
file in parts with very many short requests, which can cause longer delays
than just loading the file with one request. You can try right click and
"save as" to save the file as one file, then open it locally.
> PS also, a good priciple in web design is to have a link to the index,
> or some nav bar, else each of the page or article is a island...
Yes. Now I just have to solve my laziness and time problems :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On Aug 24, 11:31 pm, Frank Buss <····@frank-buss.de> wrote:
> ······@gmail.com wrote:
> > the issue is about design consistency, is not about whether sugar
> > syntax are convenient.
>
> > For example, this sugar syntax:
> > ´'(1 2 3)¡
> > for
> > ´(quote (1 2 3))¡
>
> > can be designed alternatively like this:
> > ´(' (1 2 3))¡
>
> > which keeps lisp's regular form (f args).
>
> But this wouldn't be very sweet syntactic sugar.
Frank, the question is not about whether that example is or is not a
sweet syntactic sugar.
The example is a illustration of a syntax sugar that are consistent
with lisp's scheme of syntax.
The example was given because you did not distinguish syntax sugars
with respect to the lisp's syntactical form (f x1 x2 x3...).
> Maybe you should try to
> use Lisp for a larger project yourself to see if it is usable.
> I think the
> way how ' is defined helps to write and read Lisp code. But you can change
> the Lisp reader, if you don't like it and create your own syntax.
remember, the criticism is one in the context of design. It's not
about “whether ispers have problems with lisp”, or whether “you have a
problem with lisp”, or whether “you like lisp?”.
Suppose you criticized the design of penny-farthing bikes, then some
fan retort: we don't have a problem with it; if you have a problem,
you can practice more; if you like equal-sized wheels, perhaps you can
call a blacksmith.
---------------------------------------------
Fundamental Problems of Lisp
Xah Lee, 2008-07
In this article, we discuss 2 problems that are rooted in lisp. One is
the irregularity in its often cited regular syntax. The other is the
language's use of “cons” for list.
Syntax Irregularities
Lisp family of languages, in particular, Common Lisp, Scheme Lisp,
Emacs Lisp, are well know for its syntax's regularity, namely,
“everything” is of the form “(f x1 x2 ...)”. However, it is little
talked about that there are several irregularities in its syntax. Here
are some examples of the syntax irregularity.
The comment syntax of semicolon to end of line “;”.
The dotted notation for cons cell “(1 . 2)”.
The single quote syntax used to hold evaluation, e.g. “'(1 2 3)”.
The backquote and comma syntax used to hold but evaluate parts of
expression, e.g. “(setq x 1) (setq myVariableAndValuePair `(x ,x))”.
The “,@” for inserting a list as elements into another list. e.g.
“(setq myListX (list 1 2)) (setq myListY (list 3 4)) (setq myListXY
`(,@ myListX ,@ myListY))”
In the following, we detail how these irregularities hamper the power
of regular syntax, and some powerful features and language
developments that lisp have missed largely due to it.
Confusing
Lisp's irregular syntax are practically confusing. For example, the
difference between “(list 1 2 3)”, “'(1 2 3)”, “(quote (1 2 3))” is a
frequently asked question. The use of “`”, “,”, “,@” etc are esoteric.
If for all these special syntactical elements use the regular form “(f
args)”, then much confusion will be reduced and people will understand
and use these features better. For example, The “'(1 2 3)” might be
changed to “(' 1 2 3)”, and
(setq myListXY `(,@ myListX ,@ myListY))
could have been:
(setq myListXY (eval-parts (splice myListX) (splice myListY)))
or with sugar syntax for typing convenience:
(setq myListXY (` (,@ myListX) (,@ myListY)))”
Syntax-Semantics Correspondence
A regular nested syntax has a one-to-one correspondence to the
language's abstract syntax tree, and to a large extent the syntax has
some correspondence to the language's semantics. The irregularities in
syntax breaks this correspondence.
For example, programers can pretty much tell what piece of source code
“(f args)” do by just reading the function's name. As a contrast, in
syntax soup languages such as Java, Perl, the programmer must be
familiar with each of its tens of syntactical forms. (e.g. “if (...)
{...}”, “for (...; ...; ...) {...}”, “(some? this: that)”, “x++”,
“myList = [1, 2, 3]” etc.) As a example, if lisp's “'(1 2 3)” is
actually “(quote 1 2 3)” or shortcut form “(' 1 2 3)”, then it is much
easier to understand.
Source Code Transformation
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. (lisp's macros is one
example) 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. Part of these reasons are political
and lisper's sensitivity to criticism of its nested parens.
Automatic, Uniform, Universal, Source Code Formatting
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.
Because lisp's syntax has lots of nested parenthesis, the source code
formatting is much more a labor intensive than syntax soup languages
such as Perl, even with dedicated lisp editor such as emacs that
contain large number editing commands on nested syntax.
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)
As a example, the Mathematica language features a pure nested syntax
similar to lisp but without irregularities. So, in that language,
since version 3 released in 1996, the source code in its editor are
automatically formatted on the fly as programer types, much in the
same way paragraphs are automatically wrapped in a word processor
since early 1990s
Syntax As Markup Language
One of the power of such pure nested 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.)
Xah
∑ http://xahlee.org/
☄
······@gmail.com wrote:
> Frank, the question is not about whether that example is or is not a
> sweet syntactic sugar.
>
> The example is a illustration of a syntax sugar that are consistent
> with lisp's scheme of syntax.
Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big,
has hairy armpits, and laughs." �XNikodemus Siivola
If it is useful, why using a more consistent, but more annoying notation?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Xah wrote:
«
Fundamental Problems of Lisp
http://xahlee.org/UnixResource_dir/writ/lisp_problems.html
»
Frank Buss wrote:
> Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big,
> has hairy armpits, and laughs." —Nikodemus Siivola
>
> If it is useful, why using a more consistent, but more annoying notation?
ultimately, you have to ask why lisper advocate nested syntax in the
first place.
if lispers love the nested syntax, then, the argument that there
should not be irregularities, has merit. If lispers think occational
irregularities of sugar syntax is good, then there's the question of
how many, or what form. You might as well introduce “i++” for “(setq i
(1+ i))”.
PS this post is posted to comp.lang.lisp,comp.lang.functional .
Xah
∑ http://xahlee.org/
☄
> (defmacro q (&rest args)
(list 'quote args))
Q
> (q a b c)
(A B C)
Why on earth you can't just do this kind of thing yourself is beyond
me.
Use the code. Be happy(er).
Realising you might throw an exception to the really ugly syntax of my
code, I felt I should post a fix:
(defmacro q (&rest args)
(list (quote quote) args))
From: Don Geddis
Subject: Re: When is Xah going to ease up on Emacs...
Date:
Message-ID: <87ljylt5g6.fsf@geddis.org>
·······@gmail.com" <······@gmail.com> wrote on Mon, 25 Aug 2008:
> ultimately, you have to ask why lisper advocate nested syntax in the
> first place.
One reason, is that it enables the very-powerful CL-style macros.
> if lispers love the nested syntax, then, the argument that there should not
> be irregularities, has merit.
No, because the macros operate on the read-in structure, not on the
surface sequence of characters.
All that matters is that every sequence of characters which corresponds to
valid lisp code, is equivalent to a known, unique, "nested syntax" data
structure. Then, all your processing (like macros) can deal with the
data structures directly, and can ignore the surface syntax.
Despite many requests, you've shown no examples on how the "irregular"
surface syntax makes anything harder for any (user) programmer.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I hope that after I die, people will say of me: "That guy sure owed me a lot of
money." -- Deep Thoughts, by Jack Handey [1999]
Dear Don,
didn't we just exchanged some dozen of messages without fruit this
week? I called you a moron, and you prob thought i'm a moron but isn't
courageous enough to say it.
perhaps it's time that you go enjoy doing your karate and i go enjoy
my masturbation?
if u really want my answers, you have to pay me consulting fee. Since
you are a great person, with gret knowledge in AI, and expert in
jujitsu, you win a big discount. Pay $1 to “xah (@) xahlee.org”
paypal, then we can resume the debate with a fresh understanding.
btw, i wrote some rambling on martial arts 2 years ago. Here:
http://xahlee.org/Periodic_dosage_dir/t1/kung-fu.html
what do u think of it?
Xah
∑ http://xahlee.org/
☄
On Aug 25, 9:39 am, Don Geddis <····@geddis.org> wrote:
> ·······@gmail.com" <······@gmail.com> wrote on Mon, 25 Aug 2008:
>
> > ultimately, you have to ask why lisper advocate nested syntax in the
> > first place.
>
> One reason, is that it enables the very-powerful CL-style macros.
>
> > if lispers love the nested syntax, then, the argument that there should not
> > be irregularities, has merit.
>
> No, because the macros operate on the read-in structure, not on the
> surface sequence of characters.
>
> All that matters is that every sequence of characters which corresponds to
> valid lisp code, is equivalent to a known, unique, "nested syntax" data
> structure. Then, all your processing (like macros) can deal with the
> data structures directly, and can ignore the surface syntax.
>
> Despite many requests, you've shown no examples on how the "irregular"
> surface syntax makes anything harder for any (user) programmer.
From: Don Geddis
Subject: Re: When is Xah going to ease up on Emacs...
Date:
Message-ID: <874p58solc.fsf@geddis.org>
·······@gmail.com" <······@gmail.com> wrote on Mon, 25 Aug 2008:
> didn't we just exchanged some dozen of messages without fruit this week?
I believe we did. Yet your failure in that thread hasn't appeared to stop
you from continuing to post your misleading opinions. Hence the unfortunate
need to continue to correct the impression you attempt to leave on c.l.l
readers.
> I called you a moron, and you prob thought i'm a moron but isn't courageous
> enough to say it.
I didn't realize that name-calling was a sign of courage.
I'll attempt to generate the courage: ...ummmm....ummmm....ummmm....
"Moron."
How'd I do?
> btw, i wrote some rambling on martial arts 2 years ago. Here:
> http://xahlee.org/Periodic_dosage_dir/t1/kung-fu.html
I enjoy how your knowledge of martial arts appears to be derived from movies
and video games.
> what do u think of it?
I think it fits in very well with the other writings at your site.
Certainly, the quality of the insights fits in.
I will have to say, I thought the tone was less insulting than usual, and the
sentence structure, grammar, and spelling, were far clearer that your usual
writing. But probably those remaining defects can be repaired with a little
additional editing.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
The dumber people think you are, the more surprised they're going to be when
you kill them. -- William Clayton
Frank Buss <··@frank-buss.de> writes:
> ······@gmail.com wrote:
>
>> the issue is about design consistency, is not about whether sugar
>> syntax are convenient.
>>
>> For example, this sugar syntax:
>> “'(1 2 3)”
>> for
>> “(quote (1 2 3))”
>>
>> can be designed alternatively like this:
>> “(' (1 2 3))”
>>
>> which keeps lisp's regular form (f args).
>
> But this wouldn't be very sweet syntactic sugar.
Doesn't matter. All these complains should be sent to the authors of
LISP. That is, 50 years back in time. Setting up a web site or
bothering cll today is idiotic. Xah needs a time machine!
--
__Pascal Bourguignon__ http://www.informatimago.com/
ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.
On Mon, 25 Aug 2008 08:51:08 +0200, Pascal J. Bourguignon wrote:
> bothering cll today is idiotic. Xah needs a time machine!
Rest assured that his colleagues at the Brotherhood of Crackpots are
already working on one :-)
Tamas
In article <··············@hubble.informatimago.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Frank Buss <··@frank-buss.de> writes:
>
> > ······@gmail.com wrote:
> >
> >> the issue is about design consistency, is not about whether sugar
> >> syntax are convenient.
> >>
> >> For example, this sugar syntax:
> >> “'(1 2 3)”
> >> for
> >> “(quote (1 2 3))”
> >>
> >> can be designed alternatively like this:
> >> “(' (1 2 3))”
> >>
> >> which keeps lisp's regular form (f args).
> >
> > But this wouldn't be very sweet syntactic sugar.
>
> Doesn't matter. All these complains should be sent to the authors of
> LISP. That is, 50 years back in time. Setting up a web site or
> bothering cll today is idiotic. Xah needs a time machine!
Please not. It could cause real damage. My Symbolics Lisp Machine
could be de-materialized if history gets changed.
--
http://lispm.dyndns.org/