Hello.
Please don't ignore this post as "just another rant about lisp
parentheses", but read on. This may not be new, but at least I try to
recognize both the merits and problems of s-expressions :)
I already touched this question last may in this group, but I'd like to
hear more what you lispers think of it.
So the question is: Could it be that people who feel uncomfortable with
lisp parentheses just can't express themselves clearly: it's not the
parentheses per se but the way they are used that bothers them.
Here is the problem (published yesterday at
http://ngrease.sourceforge.net/introduction.html#Lispdialects):
"S-expressions are fine, but as a base for domain specific languages they
have one flaw: they are not a natural match for trees. An s-expression is
either a childless singular or an anonymous list. A tree is generally
represented as an anonymous list, whose first element is _interpreted_ as
the root and the rest are _interpreted_ as the children. Not only is the
mapping to the conceptual tree indirect, but when inspected closely, the
actual language has poor _semantic density:_ 50% of it consists of
anonymous lists."
In may I wrote in c.l.l:
"Then, about the Lisp's "Head insinde parentheses" convention. Like Xah
Lee demonstrated, generating the function dynamically for a function call
is easier, if the function is inside. I have already experienced that when
writing code with ngrease, which puts the function symbol outside.
This is a very good example of how a language's primary use dictates its
design. Lisp, as a general-purpose language, is designed to make it
maximally easy to create and execute function calls.
That's why the function call is so simple and even _implicit_: it's just
an anonymous list that is _interpreted_ as a function call after a certain
convention."
(http://groups.google.com/group/comp.lang.lisp/tree/browse_frm/thread/d0ce288e1cd22654/97eaa9220225147d?rnum=341&q=xah+lee+head+expression+list&_done=%2Fgroup%2Fcomp.lang.lisp%2Fbrowse_frm%2Fthread%2Fd0ce288e1cd22654%2F8e05fc9ec8f39e3b%3Flnk%3Dst%26q%3Dxah%2Blee%2Bhead%2Bexpression%2Blist%26#doc_6dbe45651ca73f94)
What do you think? Could this be the reason why people dislike
s-expressions, but at the same time are generally quiet about
m-expressions (used in mathematica) and the groovy builder syntax (mostly
same as m-expressions but without the commas; the ngr syntax of ngrease is
based on this)? Even XML seems to get less critique than s-expressions.
All these other syntaxes are quite suitable for expressing trees. Is this
the reason they are more "acceptable" for the masses?
- Ville Oikarinen
On Oct 16, 10:27 am, Ville Oikarinen <·····@oikarinen.org> wrote:
> "S-expressions are fine, but as a base for domain specific languages they
> have one flaw: they are not a natural match for trees. An s-expression is
> either a childless singular or an anonymous list. A tree is generally
> represented as an anonymous list, whose first element is _interpreted_ as
> the root and the rest are _interpreted_ as the children.
Where are these "anonymous lists" you speak of? Are they some new-
fangled thing that Python has or something? I'm not aware of any Lisp
that has them, certainly: we have only atoms and conses, and conses
have heads and tails (which, as a kind of in-joke, we call the CAR and
CDR).
I've heard some rumours that some of the more recent Lisp dialects may
have some weasily syntax which allows you to weite (A B) instead of
(B . (B . NIL))), but I don't think anyone takes that really seriously.
On Tue, 16 Oct 2007, Tim Bradshaw wrote:
> Where are these "anonymous lists" you speak of? Are they some new-
> fangled thing that Python has or something? I'm not aware of any Lisp
> that has them, certainly: we have only atoms and conses, and conses
> have heads and tails (which, as a kind of in-joke, we call the CAR and
> CDR).
anonymous:
(green yellow)
named:
favorite-colors {green yellow}
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o04pgpsn5m.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> On Tue, 16 Oct 2007, Tim Bradshaw wrote:
>
>> Where are these "anonymous lists" you speak of? Are they some new-
>> fangled thing that Python has or something? I'm not aware of any Lisp
>> that has them, certainly: we have only atoms and conses, and conses
>> have heads and tails (which, as a kind of in-joke, we call the CAR and
>> CDR).
>
> anonymous:
>
> (green yellow)
>
> named:
>
> favorite-colors {green yellow}
A very common named list in Lisp is the alist, whose individual
element would look like
(favorite-colors green yellow)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On 2007-10-17 04:04:35 -0400, Ville Oikarinen <·····@oikarinen.org> said:
> anonymous:
>
> (green yellow)
>
> named:
>
> favorite-colors {green yellow}
named:
(defparameter *favorite-colors* (list 'green 'yellow))
named:
(let ((favorite-colors (list 'green 'yellow))
(favorite-days (list 'saturday 'sunday))
...
named:
? (defparameter *favorites-list*
(list '(favorite-colors . (green yellow))
'(favorite-things . (whiskers-on-kittens warm-woolen-mittens))))
*FAVORITES-LIST*
? (first (cdr (assoc 'favorite-things *favorites-list*)))
WHISKERS-ON-KITTENS
? (second (cdr (assoc 'favorite-things *favorites-list*)))
WARM-WOOLEN-MITTENS
?
or:
? (loop with favorite-colors = (list 'green 'yellow)
with favorite-things =
(list 'whiskers-on-kittens 'warm-woolen-mittens)
with all-favorites = (append favorite-colors favorite-things)
for element in all-favorites do
(format t "~a is one of my favorites.~%" element))
GREEN is one of my favorites.
YELLOW is one of my favorites.
WHISKERS-ON-KITTENS is one of my favorites.
WARM-WOOLEN-MITTENS is one of my favorites.
NIL
?
or:
(favorite-colors (green yellow) favorite-things (whiskers-on-kittens ...
where *your* program interprets this list structure as named lists.
You seem to keep missing the point that there is no "objective"
interpretation of list data in lisp. Your program is free to interpret
it any way you like. Saying that lisp lists are "anonymous" just means
that *you* have been interpreting them anonymously. If this is a
problem for you then just stop doing it.
Lisp programmers interpret lists as named lists all the time (look at
the association lists above, though I hesitate to suggest this lest you
think it's the only way to do it - it's not). You can interpret lists
as named lists in any number of ways.
Please also read Kent's reply down thread. I think he comes at it from
a different angle but to the same end - i.e., that you think that your
problems with your preferred uses for trees/lisp are why *others* don't
like lisp.
On Oct 17, 4:51 pm, Raffael Cavallaro
>
> You seem to keep missing the point that there is no "objective"
> interpretation of list data in lisp.
Let's just cut right to the chase:
There is no objective interpretation of list data in Lisp, because, in
fact, Lisp does not have lists as any kind of primitive type.
I'll repeat that for the hard of hearing:
LISP DOES NOT HAVE LISTS
Think about it: what data structures would you spend time on if you
were implementing a simple Lisp? Symbols, conses, and NIL is my
guess. Consider the various predicates:
NULL: primitive test
CONSP: primitive test
LISTP: (defun listp (x) (or (consp x) (null x)))
Now, OK, there are a lot of functions which walk down conses, and
there is some support for printing certain kinds of cons trees in a
special way. But this is just some superficial stuff.
That's the point I was trying to make earlier (you, Raffael,
understand this I'm sure, this isn't aimed at you): what Lisp has is
*conses*, not trees or lists or anything else. You can stitch
together conses to represent lists reasonably easily, but you could
stitch them together to represent trees, or XML, pretty easily too.
It would really not be very much work to cause Lisp to print
structures like
(a . (b . (c . [.... . nil])))
as
(a . (b c ...))
and now, suddenly, we have trees with labelled nodes. But don't let
it fool you: there are no trees, there are no lists: there are conses,
atoms, and NIL.
--tim
From: Harald Hanche-Olsen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <pcoprzdk4k2.fsf@shuttle.math.ntnu.no>
+ Tim Bradshaw <··········@tfeb.org>:
> But don't let it fool you: there are no trees, there are no lists:
And, of course, there is no spoon.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: Ken Tilton
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <wBuRi.67$V76.55@newsfe12.lga>
Harald Hanche-Olsen wrote:
> + Tim Bradshaw <··········@tfeb.org>:
>
>
>>But don't let it fool you: there are no trees, there are no lists:
>
>
> And, of course, there is no spoon.
>
And C has no strings.
kt
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
On Oct 17, 6:57 pm, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
:
>
> And, of course, there is no spoon.
>
There are, in fact, spoons. Silver ones.
From: Harald Hanche-Olsen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <pcoprzc1nyw.fsf@shuttle.math.ntnu.no>
+ Tim Bradshaw <··········@tfeb.org>:
> On Oct 17, 6:57 pm, Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> :
>>
>> And, of course, there is no spoon.
>>
>
> There are, in fact, spoons. Silver ones.
At the risk of stating the obvious: Every fool can see that Lisp has
lists. And we can do all sorts of interesting things with them: We
can make lists share the same tail, or insert stuff in the middle of a
list, and so on. The reason we can do this is, as you pointed out
upstream, that really there are no lists after all. Same thing with
the spoons. Once you realize there is no spoon, you can bend the
spoon into all sorts of shapes using your mind.
(Vs gur nobir znxrf ab frafr, lbh unira'g frra gur Zngevk zbivrf.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: John Thingstad
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <op.t0ctw3ihpqzri1@pandora.upc.no>
P� Wed, 17 Oct 2007 18:39:10 +0200, skrev Tim Bradshaw
<··········@tfeb.org>:
> On Oct 17, 4:51 pm, Raffael Cavallaro
>>
>> You seem to keep missing the point that there is no "objective"
>> interpretation of list data in lisp.
>
> Let's just cut right to the chase:
>
> There is no objective interpretation of list data in Lisp, because, in
> fact, Lisp does not have lists as any kind of primitive type.
>
> I'll repeat that for the hard of hearing:
>
> LISP DOES NOT HAVE LISTS
>
(list 1 2 3)
> Think about it: what data structures would you spend time on if you
> were implementing a simple Lisp? Symbols, conses, and NIL is my
> guess. Consider the various predicates:
>
> NULL: primitive test
> CONSP: primitive test
> LISTP: (defun listp (x) (or (consp x) (null x)))
>
> Now, OK, there are a lot of functions which walk down conses, and
> there is some support for printing certain kinds of cons trees in a
> special way. But this is just some superficial stuff.
>
Sure let's go back to assembly. A cons cell is just two 32 bit addresses
on my machine (except for chars and finums). What is your point exactry?
From: John Thingstad
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <op.t0ct71l1pqzri1@pandora.upc.no>
P� Wed, 17 Oct 2007 20:35:17 +0200, skrev John Thingstad
<··············@chello.no>:
> P� Wed, 17 Oct 2007 18:39:10 +0200, skrev Tim Bradshaw
> <··········@tfeb.org>:
>
>> On Oct 17, 4:51 pm, Raffael Cavallaro
>>>
>>> You seem to keep missing the point that there is no "objective"
>>> interpretation of list data in lisp.
>>
>> Let's just cut right to the chase:
>>
>> There is no objective interpretation of list data in Lisp, because, in
>> fact, Lisp does not have lists as any kind of primitive type.
>>
>> I'll repeat that for the hard of hearing:
>>
>> LISP DOES NOT HAVE LISTS
>>
>
> (list 1 2 3)
>
>> Think about it: what data structures would you spend time on if you
>> were implementing a simple Lisp? Symbols, conses, and NIL is my
>> guess. Consider the various predicates:
>>
>> NULL: primitive test
>> CONSP: primitive test
>> LISTP: (defun listp (x) (or (consp x) (null x)))
>>
>> Now, OK, there are a lot of functions which walk down conses, and
>> there is some support for printing certain kinds of cons trees in a
>> special way. But this is just some superficial stuff.
>>
>
> Sure let's go back to assembly. A cons cell is just two 32 bit addresses
> on my machine (except for chars and finums). What is your point exactry?
OK, I'm a idiot, that is exactly what you ment..
lol
On Oct 17, 7:41 pm, "John Thingstad"
>
> OK, I'm a idiot, that is exactly what you ment..
That kind of is my point. There is some low-level implementational
stuff, which traditionally was things like conses, symbols and numbers
of various kinds, as well as may be some other sorts of object, and
now would include structures, CLOS instances of various kinds, arrays
and so on. Lists are not one of these types of objects: they're
something you implement later based on the primitive things you have.
Note that this means that, for instance, arrays and CLOS instances are
implementationally *more* primitive than lists.
Now i's clear that, just as you can implement convenient operatonal
(constructors, accessors etc) and syntactic support for lists, you
could obviously do the same for tress (however you want to define
them). I mean, it really would not be very hard. Some languages have
done that - Prolog is an example I can think off off hand.
But Lisp hasn't done this. So, well, one of the following needs to be
the case:
- Lisp people are all fools;
- Trees don't actually matter that much;
- representing trees as lists is just fine;
I think the latter two are probably close to the truth.
On Thu, 18 Oct 2007, Tim Bradshaw wrote:
> But Lisp hasn't done this. So, well, one of the following needs to be
> the case:
> - Lisp people are all fools;
> - Trees don't actually matter that much;
> - representing trees as lists is just fine;
>
> I think the latter two are probably close to the truth.
Me too. This is what I have been repeating: different problems require
different tools.
So now that there seems to be at least some kind of a concensus about the
fact that s-expressions work better with lists than with trees, maybe we
can discuss the latter part of my original post: could it be so that
people feel (unconsciously) uncomfortable when they want to think the data
as trees but the syntax somehow doesn't feel right because it's about
lists?
We could argue forever whether (or when) it's stupid to think things as
trees, but _if_ a user thinks trees, is this why he doesn' feel
comfortable with s-expressions?
- Ville Oikarinen
On Oct 18, 10:01 am, Ville Oikarinen <·····@oikarinen.org> wrote:
> On Thu, 18 Oct 2007, Tim Bradshaw wrote:
> > But Lisp hasn't done this. So, well, one of the following needs to be
> > the case:
> > - Lisp people are all fools;
> > - Trees don't actually matter that much;
> > - representing trees as lists is just fine;
>
> > I think the latter two are probably close to the truth.
>
> Me too. This is what I have been repeating: different problems require
> different tools.
>
> So now that there seems to be at least some kind of a concensus about the
> fact that s-expressions work better with lists
I'd certainly differ from any such consensus. The third point is
pretty critical here: there is absolutely no problem representing
trees as s-expressions (which I should have written instead of "list"
above) in my opinion, when you need to do that.
Those of us who have spend some time dealing with representations
which force a tree-like view on the world (*ML is the canonical recent
example) can probably confirm that converting that representation to s-
expressions leads to a huge increase in tractability. Some of us have
written substantial systems which are entirely based around using an S-
expression representation of these tree-based systems.
This is kind of one of these stupid arguments about word order in
natural languages dressed up, where someone will start claiming that,
of course, SVO is better than SOV or VSO (Lisp is a VSO language
BTW). Anyone who has made any serious study of natural languages will
realist that these kind of differences are just not the point: they're
superficial matters of syntax which have basically no impact on human
performance. The same is true for these issues: a human being can
learn, very fast, to deal with these small differences in surface
syntax.
The fact that these debates continue says rather more about the
relation between programmers and human beings than it does anything
else.
OK, I'm done now.
From: Espen Vestre
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <m1przchk1p.fsf@vestre.net>
Tim Bradshaw <··········@tfeb.org> writes:
> But Lisp hasn't done this. So, well, one of the following needs to be
> the case:
> - Lisp people are all fools;
> - Trees don't actually matter that much;
> - representing trees as lists is just fine;
>
> I think the latter two are probably close to the truth.
I agree. I think the xml mindset does a lot of damage here - one tries
to force everything into tree-like structures, even things which
really is better thought of as unordered sets of complex objects. In
the real life cases where you actually /have/ tree-like structures,
the nodes often contain a lot of information, not only "labels", so
they are typically implemented as CLOS objects with their own child
pointers.
This whole discussion is really Much Ado About Nothing :-(
--
(espen)
On Thu, 18 Oct 2007, Espen Vestre wrote:
> I agree. I think the xml mindset does a lot of damage here - one tries
> to force everything into tree-like structures, even things which
> really is better thought of as unordered sets of complex objects. In
> the real life cases where you actually /have/ tree-like structures,
> the nodes often contain a lot of information, not only "labels", so
> they are typically implemented as CLOS objects with their own child
> pointers.
Like I said earlier, there are lots of "forced" trees (I mentioned the
filesystem as an example) that harm our thinking.
Still, it's not about trees having "only" labels. I see it this way: the
difference between a list (b c) and a tree a {b c} is that the tree is
kind of a list (child list) "with" a label, and the list is "only" a list.
The "label" can be interpreted as a type, for example. An object can be
represented as a tree, where its type (class) is the root, and all fields
and methods are children.
(And again, everything can be expressed as lists and sets, too, but tree
is the only of these three that explicitly supports a hierarchy between
the contained objects.)
- Ville Oikarinen
On Thu, 18 Oct 2007 09:14:24 +0000, Ville Oikarinen wrote:
> Still, it's not about trees having "only" labels. I see it this way: the
> difference between a list (b c) and a tree a {b c} is that the tree is
> kind of a list (child list) "with" a label, and the list is "only" a list.
Huh? For (B C) i see a tree B with one child node C. For a {b c} i see an
anonymous letter 'a' and an anonymous set '{b c}'.
Surely this now proves that s-expressions are better for trees, while ngr
syntax seems only good for anonymous letters and sets. Surely.
drewc
> Surely lisp is better
> (And again, everything can be expressed as lists and sets, too, but tree
> is the only of these three that explicitly supports a hierarchy between
> the contained objects.
>
> - Ville Oikarinen
--
Posted via a free Usenet account from http://www.teranews.com
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Thu, 18 Oct 2007, Espen Vestre wrote:
>
> > I agree. I think the xml mindset does a lot of damage here - one tries
> > to force everything into tree-like structures, even things which
> > really is better thought of as unordered sets of complex objects. In
> > the real life cases where you actually /have/ tree-like structures,
> > the nodes often contain a lot of information, not only "labels", so
> > they are typically implemented as CLOS objects with their own child
> > pointers.
>
> Like I said earlier, there are lots of "forced" trees (I mentioned the
> filesystem as an example) that harm our thinking.
>
> Still, it's not about trees having "only" labels. I see it this way: the
> difference between a list (b c) and a tree a {b c} is that the tree is
> kind of a list (child list) "with" a label, and the list is "only" a list.
>
> The "label" can be interpreted as a type, for example. An object can be
> represented as a tree, where its type (class) is the root, and all fields
> and methods are children.
Lists are more primitive. They allow two interpretations
1) one is list based, just read it and you get the list data structures
(which are in Common Lisp based on cons cells)
1a) you can leave it that way
1b) you can traverse the internal list-based data-structure
and create some other data-structure
2) one is based on a custom parser that generates other
data structures
>
> (And again, everything can be expressed as lists and sets, too, but tree
> is the only of these three that explicitly supports a hierarchy between
> the contained objects.)
The Lisp list is basically only a shorthand notation
for binary trees. It already knows about hierarchies.
Touretsky wrote SDRAW-LOOP, which is a top-level with an added
printer based on 2d printing of cons cells:
http://www.cs.cmu.edu/~dst/Lisp/sdraw/
RJMBP:~ joswig$ openmcl
Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
? (load "/Lisp/sdraw-generic.lisp")
#P"/Lisp/sdraw-generic.lisp"
? (sdraw-loop)
Type any Lisp expression, or :ABORT to exit.
S> '(* (+ 2 (sin b)) (cos a))
[*|*]--->[*|*]------------------------------------>[*|*]---> NIL
| | |
v v v
* [*|*]--->[*|*]--->[*|*]---> NIL [*|*]--->[*|*]---> NIL
| | | | |
v v v v v
+ 2 [*|*]--->[*|*]---> NIL COS A
| |
v v
SIN B
Result: (* (+ 2 (SIN B)) (COS A))
S> '((klaus :male) (herbert :male) (martha :female))
[*|*]------------------>[*|*]------------------->[*|*]---> NIL
| | |
v v v
[*|*]--->[*|*]---> NIL [*|*]---->[*|*]---> NIL [*|*]--->[*|*]---> NIL
| | | | | |
v v v v v v
KLAUS :MALE HERBERT :MALE MARTHA :FEMALE
Result: ((KLAUS :MALE) (HERBERT :MALE) (MARTHA :FEMALE))
S>
It also has an inspector:
? (scrawl (copy-tree '(* (+ 2 (sin b)) (cos a))))
Crawl through list: 'H' for help, 'Q' to quit.
[*|*]--->[*|*]------------------------------------>[*|*]---> NIL
| | |
v v v
* [*|*]--->[*|*]--->[*|*]---> NIL [*|*]--->[*|*]---> NIL
| | | | |
v v v v v
+ 2 [*|*]--->[*|*]---> NIL COS A
| |
v v
SIN B
'(* (+ 2 (SIN B)) (COS A))
SCRAWL> h
Legal commands: A)car D)cdr B)back up
S)start Q)quit H)help
SCRAWL> a
*
(car '(* (+ 2 (SIN B)) (COS A)))
SCRAWL> b
[*|*]--->[*|*]------------------------------------>[*|*]---> NIL
| | |
v v v
* [*|*]--->[*|*]--->[*|*]---> NIL [*|*]--->[*|*]---> NIL
| | | | |
v v v v v
+ 2 [*|*]--->[*|*]---> NIL COS A
| |
v v
SIN B
'(* (+ 2 (SIN B)) (COS A))
SCRAWL> d
[*|*]------------------------------------>[*|*]---> NIL
| |
v v
[*|*]--->[*|*]--->[*|*]---> NIL [*|*]--->[*|*]---> NIL
| | | | |
v v v v v
+ 2 [*|*]--->[*|*]---> NIL COS A
| |
v v
SIN B
(cdr '(* (+ 2 (SIN B)) (COS A)))
SCRAWL> d
[*|*]---> NIL
|
v
[*|*]--->[*|*]---> NIL
| |
v v
COS A
(cddr '(* (+ 2 (SIN B)) (COS A)))
SCRAWL> a
[*|*]--->[*|*]---> NIL
| |
v v
COS A
(caddr '(* (+ 2 (SIN B)) (COS A)))
SCRAWL> d
[*|*]---> NIL
|
v
A
(cdaddr '(* (+ 2 (SIN B)) (COS A)))
SCRAWL>
On Wed, 17 Oct 2007, Tim Bradshaw wrote:
> I'll repeat that for the hard of hearing:
>
> LISP DOES NOT HAVE LISTS
Yes, that's of course true.
But I'm not really talking about lisp, I'm talking about s-expressions as
a syntax.
And the string "(a b c)" is a list for a user of the syntax (at least from
my point of view i.e. domain-specific modeling), no matter how a given
language that made the s-expression famous implements it as conses.
- Ville Oikarinen
> But I'm not really talking about lisp, I'm talking about s-expressions as
> a syntax.
>
> And the string "(a b c)" is a list for a user of the syntax (at least from
> my point of view i.e. domain-specific modeling), no matter how a given
> language that made the s-expression famous implements it as conses.
If syntax is the problem, it's not very interesting in the context of
Common Lisp, because it allows you to define your own syntax. You
don't need to convince anyone in order to improve things. Instead of
implementing a new language, you could just as well write a reader
macro for your new data structure and start to use it. You may
discover one of two things:
1. Your idea isn't as great as you thought. In this case, you can
either look for improvements of the idea and try again or discard it.
2. You're much more productive than before, because your idea is very
useful. In this case, you actually have evidence in support of your
syntax (for your specific problem, at least), which might give its
usefulness some credibility and encourage others to investigate or
even adopt it.
Noone wants to discourage you from experimenting. Experimentation is
a very useful thing to do. Asking questions doesn't hurt either, as
long as you're still looking for ideas. In contrast, arguing about
how you _may_ want to revise Lisp syntax for everyone at once while
already having a good idea of what the result ought to look like isn't
very productive at all.
Just try it, then come back with the results. Announcing your project
and looking for testers/contributors is fine and sharing your ideas is
nice, but still arguing about the superiority of your tree definition
approach after the 70th posting in this thread while stating the same
opinion over and over makes you look like someone who probably wants
to sell something (or at least like someone who gets a kick out of
arguing just for the sake of it, which doesn't improve the signal-to-
noise ratio on comp.lang.lisp either).
~ Matthias
On Thu, 18 Oct 2007, Matthias Benkard wrote:
> If syntax is the problem, it's not very interesting in the context of
> Common Lisp, because it allows you to define your own syntax.
This could work. Alas, I don't have time or skills to verify that.
> In contrast, arguing about how you _may_ want to revise Lisp syntax for
> everyone at once while already having a good idea of what the result
> ought to look like isn't very productive at all.
Here I go again, repeating myself: No, it's not. And I'm not arguing about
how I may want to revise Lisp syntax. I don't want to revise Lisp syntax.
> Just try it, then come back with the results. Announcing your project
> and looking for testers/contributors is fine and sharing your ideas is
> nice, but still arguing about the superiority of your tree definition
> approach after the 70th posting in this thread while stating the same
> opinion over and over makes you look like someone who probably wants
> to sell something
First, I can't take the credit: ngr is very heavily based on the groovy
builder syntax. And there are lots of other tree oriented syntaxes:
Mathematica has also had much influence in my thinking.
Second, I don't claim absolute superiority. S-expressions work better for
things lisp is designed and used for.
Third, the "after the 70th posting" argument cuts both ways.
- Ville Oikarinen
Tim Bradshaw <··········@tfeb.org> writes:
> It would really not be very much work to cause Lisp to print
> structures like
>
> (a . (b . (c . [.... . nil])))
>
> as
>
> (a . (b c ...))
>
> and now, suddenly, we have trees with labelled nodes. But don't let
> it fool you: there are no trees, there are no lists: there are conses,
> atoms, and NIL.
I take that as a challenge, I keep meaning to learn to use
the pretty printer. This looks like a start:
CL-USER> (defparameter *tree-table*
(copy-pprint-dispatch))
*TREE-TABLE*
CL-USER> (set-pprint-dispatch '(cons symbol)
(lambda(stream object)
(write-char #\( stream)
(write (car object) :stream stream)
(format stream " . ")
(pprint-logical-block (stream (cdr object)
:prefix "("
:suffix ")")
(pprint-exit-if-list-exhausted)
(write (pprint-pop) :stream stream)
(loop (pprint-exit-if-list-exhausted)
(write-char #\space stream)
(write (pprint-pop) :stream stream)))
(write-char #\) stream))
0
*tree-table*)
; Compiling LAMBDA (PRETTY-PRINT::OBJECT):
; Compiling Top-Level Form:
NIL
CL-USER> (let ((*print-pprint-dispatch* *tree-table*))
(write '(a b (c d e) (f (x 1 2)(y 3 4 5)(z 6 7 8 9 10) ))))
(A . (B (C . (D E)) (F . ((X . (1 2)) (Y . (3 4 5)) (Z . (6 7 8 9 10))))))
(A B (C D E) (F (X 1 2) (Y 3 4 5) (Z 6 7 8 9 10)))
but I need to put conditional new lines in there somewhere,
and I'm not sure about repeating STREAM all over the place.
Alan Crowe
Edinburgh
Scotland
On Wed, 17 Oct 2007, Raffael Cavallaro wrote:
>
> where *your* program interprets this list structure as named lists.
>
> You seem to keep missing the point that there is no "objective"
> interpretation of list data in lisp. Your program is free to interpret
> it any way you like. Saying that lisp lists are "anonymous" just means
> that *you* have been interpreting them anonymously. If this is a
> problem for you then just stop doing it.
No, I don't miss that point. Lists _can_ be interpreted in a lot of ways.
And trees _can_ be expressed as lists in lisp.
My whole point is that in order to be able to express lists, you _need_ to
interprete lists as trees.
> Lisp programmers interpret lists as named lists all the time (look at
> the association lists above, though I hesitate to suggest this lest you
> think it's the only way to do it - it's not). You can interpret lists
> as named lists in any number of ways.
Sure. Again, it's _possible_, and even works very well in practice. But a
syntax designed for _tree_ manipulation instead of _list_ manipulation
(like somebody else said, it's in the name of the lisp language) works
even better.
> Please also read Kent's reply down thread. I think he comes at it from
> a different angle but to the same end - i.e., that you think that your
> problems with your preferred uses for trees/lisp are why *others* don't
> like lisp.
Yes, I do think that. But that was the speculation part, which I expressed
as a question in the original post. And seems that I don't get many "yes"
answers here :)
- Ville Oikarinen
On Oct 17, 9:04 am, Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Tim Bradshaw wrote:
> > Where are these "anonymous lists" you speak of? Are they some new-
> > fangled thing that Python has or something? I'm not aware of any Lisp
> > that has them, certainly: we have only atoms and conses, and conses
> > have heads and tails (which, as a kind of in-joke, we call the CAR and
> > CDR).
>
> anonymous:
>
> (green yellow)
>
> named:
>
> favorite-colors {green yellow}
Named:
(favorite-colors . (green yellow))
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710161230550.9142@ttleush>
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
> All these other syntaxes are quite suitable for expressing trees. Is this
> the reason they are more "acceptable" for the masses?
>
Here is my theory:
The reason s-expressions sometimes gets critique is because lispers often
claim that s-expressions are simple and beautiful. A very few number of
those who don't think so (which can be for various reasons, but most
likely because they don't have much lisp programming experience which is
important to understand how practical s-expressions are and how easy they
are to write and edit) gets provocated by such a claim and therefore get
an urge to criticize the s-expression based on non-rational or uninformed
arguments such as those you listed above.
On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
> The reason s-expressions sometimes gets critique is because lispers often
> claim that s-expressions are simple and beautiful. A very few number of
> those who don't think so (which can be for various reasons, but most
> likely because they don't have much lisp programming experience which is
> important to understand how practical s-expressions are and how easy they
> are to write and edit) gets provocated by such a claim and therefore get
> an urge to criticize the s-expression based on non-rational or uninformed
> arguments such as those you listed above.
I'd like to hear more details. What is "non-rational" and "uninformed" in
my post?
- Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710161301000.9142@ttleush>
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
>
>
> On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
>
>> The reason s-expressions sometimes gets critique is because lispers often
>> claim that s-expressions are simple and beautiful. A very few number of
>> those who don't think so (which can be for various reasons, but most
>> likely because they don't have much lisp programming experience which is
>> important to understand how practical s-expressions are and how easy they
>> are to write and edit) gets provocated by such a claim and therefore get
>> an urge to criticize the s-expression based on non-rational or uninformed
>> arguments such as those you listed above.
>
> I'd like to hear more details. What is "non-rational" and "uninformed" in
> my post?
>
> "S-expressions are fine, but as a base for domain specific languages
> they have one flaw: they are not a natural match for trees.
S-expression is a very natural match for trees since s-expressions
consists of cells having one pointer to a sub three (car), and one
pointer to the next leaf (cdr).
> An s-expression is either a childless singular or an anonymous list.
I don't think this guy knows what an s-expression is, and I think his
arguments are non-rational.
> What do you think? Could this be the reason why people dislike
> s-expressions, but at the same time are generally quiet about
> m-expressions (used in mathematica) and the groovy builder syntax
> (mostly same as m-expressions but without the commas; the ngr syntax of
> ngrease is based on this)? Even XML seems to get less critique than
> s-expressions.
I think this is uninformed. Do you have any numbers? And what kind of
critique are we talking about?
On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
> > "S-expressions are fine, but as a base for domain specific languages
> > they have one flaw: they are not a natural match for trees.
>
> S-expression is a very natural match for trees since s-expressions
> consists of cells having one pointer to a sub three (car), and one
> pointer to the next leaf (cdr).
No, that is a natural match for a linked list. A tree isn't like that.
(Sure, s-expressions and linked lists are a clever implementation for
trees, but conceptually they differ quite a lot.)
Besides, if we ignore the lisp language for a while and just talk about
s-expressions, cons cells are just one implementation for them. At the
syntax level they are not a requirement.
> > An s-expression is either a childless singular or an anonymous list.
>
> I don't think this guy knows what an s-expression is, and I think his
> arguments are non-rational.
Well, in that case I would be very grateful for a correction. What in the
above statement is incorrect?
> > What do you think? Could this be the reason why people dislike
> > s-expressions, but at the same time are generally quiet about
> > m-expressions (used in mathematica) and the groovy builder syntax
> > (mostly same as m-expressions but without the commas; the ngr syntax of
> > ngrease is based on this)? Even XML seems to get less critique than
> > s-expressions.
>
> I think this is uninformed. Do you have any numbers? And what kind of
> critique are we talking about?
Yes, that was the speculation part of my post (See the words "could" and
"seems"?). Never mind if I don't have an answer or a proof for it.
- Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710161325390.9142@ttleush>
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
> On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
>
>>> "S-expressions are fine, but as a base for domain specific languages
>>> they have one flaw: they are not a natural match for trees.
>>
>> S-expression is a very natural match for trees since s-expressions
>> consists of cells having one pointer to a sub three (car), and one
>> pointer to the next leaf (cdr).
>
> No, that is a natural match for a linked list. A tree isn't like that.
> (Sure, s-expressions and linked lists are a clever implementation for
> trees, but conceptually they differ quite a lot.)
>
> Besides, if we ignore the lisp language for a while and just talk about
> s-expressions, cons cells are just one implementation for them. At the
> syntax level they are not a requirement.
>
Okay, I didn't understand the intention then. I think you may need to work
on making your text clearer though. How about at least giving some
examples?
On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
> Okay, I didn't understand the intention then. I think you may need to work
> on making your text clearer though. How about at least giving some
> examples?
Please see my response to your robot arm example.
- Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710161336440.9142@ttleush>
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
> On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
>
>> Okay, I didn't understand the intention then. I think you may need to work
>> on making your text clearer though. How about at least giving some
>> examples?
>
> Please see my response to your robot arm example.
>
That wasn't me. But anyway, your critiqe about the s-expression example
was this:
"the required colon and quote are just minor noise and not the
point."
The colon and quote were necesarry to make the represantation correct,
and therefore your argument was non-rational.
It also seems like you don't like that the next element in
a list belongs to the keyword before because you have to "_interpret_"
that it does so. Thats not a rational argument, because text is an
abstract representation which has to be interpreted anyway.
Besides, there are other ways to represent the same structure using
s-expressions where you don't have to interpret that specific thing.
Your own version, which I believe you think is better, looks like this:
"
hand {
type:box
display-controls: color:green
center: $:translate... #:"some code"
...
}
"
Its understandable that you like better code you understand well
yourself. But that is not a rational argument against s-expressions.
On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
> That wasn't me. But anyway, your critiqe about the s-expression example
> was this:
>
> "the required colon and quote are just minor noise and not the
> point."
>
> The colon and quote were necesarry to make the represantation correct,
> and therefore your argument was non-rational.
No, that wasn't the point of my critique. Yes, they are required for
technical reasons, and I wasn't complaining about them, which I quite
clearly say in your quote, visible above.
> It also seems like you don't like that the next element in
> a list belongs to the keyword before because you have to "_interpret_"
> that it does so. Thats not a rational argument, because text is an
> abstract representation which has to be interpreted anyway.
You seem to begin to arrive at the core of the problem: you start to refer
to the s-expression as "text".
Which _is_ my point: in this context it has the drawbacks of "text", when
its purpose would be more than text, a _tree_.
> Besides, there are other ways to represent the same structure using
> s-expressions where you don't have to interpret that specific thing.
See my other post about the family tree. How can s-expressions be used so
that "me" really is a child of "my-father", and "my-father" a child of
"my-grandfather"? And that 60% of the data is not about anonymous lists?
> Its understandable that you like better code you understand well
> yourself. But that is not a rational argument against s-expressions.
No it isn't. And that's why I didn't use it as an argument. My critique is
based on more objective arguments.
(In fact, for certain things I would probably prefer s-expressions.)
- Ville Oikarinen
On 2007-10-16 08:08:37 -0400, Ville Oikarinen <·····@oikarinen.org> said:
> See my other post about the family tree. How can s-expressions be used so
> that "me" really is a child of "my-father", and "my-father" a child of
> "my-grandfather"? And that 60% of the data is not about anonymous lists?
Insofar as s-expressions are interpreted strictly as cons cells, this
cannot be done, since each cons can have one and only one child, and a
tree node can have arbitrarily many.
The point you seem to keep missing imho is that this matters not the
slightest because you, the programmer, decide how lisp lists (more
generally, conses) will be interpreted as data in *your* program.
So both of these do what you want *if* your program reads them properly:
(grandad grandma
(me
(my-son my-daughter)
(my-sister
(my-niece my-other-niece)
(my-brother
(my-other-other-niece))
Or:
(grandad
:spouse my-mom
:children ((me :children
(my-son my-daughter)
:spouse my-wife)
(my-sister :spouse my-brother-in-law
:children
(my-niece my-other-niece))
(my-brother :children
(my-other-other-niece)))
IOW, your program is free to put any interpretation, including a
tree-like genealogical one, on list data.
You're asking for s-expressions to natively be a perfect fit for *your*
common-use case. This is unreasonable, especially when you are
completely free to read s-expressions as data in any way you choose.
S-expressions are successful because, in combination with the other
facilities of the language, they are flexible enough to be used for
*many* data wants, not just the labeled trees you want so much.
In many ways your post reminds me of a certain pond splasher who hops
in and out of c.l.l - you think that because you want something the
whole world must really want it to be the *default* too.
On Tue, 16 Oct 2007, Raffael Cavallaro wrote:
> You're asking for s-expressions to natively be a perfect fit for *your*
> common-use case. This is unreasonable, especially when you are
> completely free to read s-expressions as data in any way you choose.
> S-expressions are successful because, in combination with the other
> facilities of the language, they are flexible enough to be used for
> *many* data wants, not just the labeled trees you want so much.
I agree that the power of s-expression (and lisps in general) is their
almost perfect match for virtually anything.
I think it's inevitable and very common that general solutions never work
as ideally for a given narrow problem as a custom-tailored solution. SQL
works better with relational databases as general purpose languages,
regular expressions handle strings better than general purpose
languages...
> In many ways your post reminds me of a certain pond splasher who hops
> in and out of c.l.l - you think that because you want something the
> whole world must really want it to be the *default* too.
What are you talking about? I have suggested absolutely no changes to
anything at all!
S-expressions work very well as a general tool, period.
For situations where tree structures dominate and the things s-expressions
are superior don't, ngr works better. What ngr doesn't work so well is
generating a function for a function call, for example. And it's ok,
because (mostly constant) trees are what ngrease is designed for. And
general purpose programming with lots of (dynamically generated) function
calls is what lisps are for.
It's as simple as that: different tools are designed for different
problems.
- Ville Oikarinen
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
>
> > That wasn't me. But anyway, your critiqe about the s-expression example
> > was this:
> >
> > "the required colon and quote are just minor noise and not the
> > point."
> >
> > The colon and quote were necesarry to make the represantation correct,
> > and therefore your argument was non-rational.
>
> No, that wasn't the point of my critique. Yes, they are required for
> technical reasons, and I wasn't complaining about them, which I quite
> clearly say in your quote, visible above.
>
> > It also seems like you don't like that the next element in
> > a list belongs to the keyword before because you have to "_interpret_"
> > that it does so. Thats not a rational argument, because text is an
> > abstract representation which has to be interpreted anyway.
>
> You seem to begin to arrive at the core of the problem: you start to refer
> to the s-expression as "text".
They are. They are an external data-format based on text.
>
> Which _is_ my point: in this context it has the drawbacks of "text", when
> its purpose would be more than text, a _tree_.
S-expressions are an external format for a certain kind
of lists, not 'trees'.
>
> > Besides, there are other ways to represent the same structure using
> > s-expressions where you don't have to interpret that specific thing.
>
> See my other post about the family tree. How can s-expressions be used so
> that "me" really is a child of "my-father", and "my-father" a child of
> "my-grandfather"? And that 60% of the data is not about anonymous lists?
>
> > Its understandable that you like better code you understand well
> > yourself. But that is not a rational argument against s-expressions.
>
> No it isn't. And that's why I didn't use it as an argument. My critique is
> based on more objective arguments.
There are no 'objective' arguments. All arguments by humans
are subjective and depend on assumptions, experience, historic
context, likes, dislikes, purpose, and so on.
>
> (In fact, for certain things I would probably prefer s-expressions.)
Lisp programmers like s-expression because they are useful in the
context of the language and related tools. S-expressions alone
have less value.
>
> - Ville Oikarinen
On Tue, 16 Oct 2007, Rainer Joswig wrote:
> > You seem to begin to arrive at the core of the problem: you start to refer
> > to the s-expression as "text".
>
> They are. They are an external data-format based on text.
>
> >
> > Which _is_ my point: in this context it has the drawbacks of "text", when
> > its purpose would be more than text, a _tree_.
>
> S-expressions are an external format for a certain kind
> of lists, not 'trees'.
Amen. Exactly my point. S-expressions are (anonymous) lists. And for many
(most?) domain-specific purposes I want trees.
> > > Its understandable that you like better code you understand well
> > > yourself. But that is not a rational argument against s-expressions.
> >
> > No it isn't. And that's why I didn't use it as an argument. My critique is
> > based on more objective arguments.
>
> There are no 'objective' arguments. All arguments by humans
> are subjective and depend on assumptions, experience, historic
> context, likes, dislikes, purpose, and so on.
What's the practical value of that philosophy? That your subjective
response to my subjective response just produced more heat than it was
worth and the universe is a few steps closer to its death at infinite
entropy :)
Come on, of course my opinions are basically subjective, based on my
interpretation of the shadows on the cave walls, but try to adopt some
shades of grey here and discuss the arguments themselves instead of just
vaguely dismissing them as "subjective and irrational".
- Ville Oikarinen
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Rainer Joswig wrote:
>
> > > You seem to begin to arrive at the core of the problem: you start to
> > > refer
> > > to the s-expression as "text".
> >
> > They are. They are an external data-format based on text.
> >
> > >
> > > Which _is_ my point: in this context it has the drawbacks of "text", when
> > > its purpose would be more than text, a _tree_.
> >
> > S-expressions are an external format for a certain kind
> > of lists, not 'trees'.
>
> Amen. Exactly my point. S-expressions are (anonymous) lists. And for many
> (most?) domain-specific purposes I want trees.
>
> > > > Its understandable that you like better code you understand well
> > > > yourself. But that is not a rational argument against s-expressions.
> > >
> > > No it isn't. And that's why I didn't use it as an argument. My critique
> > > is
> > > based on more objective arguments.
> >
> > There are no 'objective' arguments. All arguments by humans
> > are subjective and depend on assumptions, experience, historic
> > context, likes, dislikes, purpose, and so on.
>
> What's the practical value of that philosophy? That your subjective
> response to my subjective response just produced more heat than it was
> worth and the universe is a few steps closer to its death at infinite
> entropy :)
>
> Come on, of course my opinions are basically subjective, based on my
> interpretation of the shadows on the cave walls, but try to adopt some
> shades of grey here and discuss the arguments themselves instead of just
> vaguely dismissing them as "subjective and irrational".
You have mentioned that you are using objective arguments. Which
usually can be translated to 'it is my strong opinion'.
Nothing more.
See above your sentence: ' And for many (most?) domain-specific purposes
I want trees. '. The word 'want' already shows that your wish
is totally subjective. There are many general purpose
data representations you could have chosen: trees, lists, tables,
graphs, ... But for some subjective reason you prefer trees.
Many people working for example with financial data would
prefer tables.
Preference of Lisp s-expressions is also totally subjective,
based on the perceived usefulness of the technical eco-system
they are used with. For s-expressions alone there is
less enthusiasm. Only together with, say, a simple reader
and other tools (say, a Lisp system, a S-expression-aware
editor, ...) it becomes valuable.
>
> - Ville Oikarinen
On Tue, 16 Oct 2007, Rainer Joswig wrote:
> See above your sentence: ' And for many (most?) domain-specific purposes
> I want trees. '. The word 'want' already shows that your wish
> is totally subjective.
Yes, those arguments are (partly) subjective. I didn't claim that _all_ my
arguments are objective. In fact, I didn't even say any of my arguments
are "objective", just "more objective" (than liking ngr more than s-expr).
Anyway, enough of this meta-argumentation. From now on I'll only post
actual arguments and comment actual arguments about the actual subject.
> There are many general purpose data representations you could have
> chosen: trees, lists, tables, graphs, ... But for some subjective
> reason you prefer trees. Many people working for example with financial
> data would prefer tables.
Sure. There are different data structures. And there are lots of choices
for the base structure that can be used to express the others.
For example a table is easily represented as a tree:
table {
column {
row {...}
row {...}
}
...
}
Yes, it is a subjective choice to treat tree as the fundamental and most
"natural" structure for representing data. In fact, computers probably
would choose array... :)
Anyway, even if I was the only person that wanted trees, you can probably
still evaluate how well s-expressions suit _my_ needs, right?
Besides, I don't think I'm so excpetional when I treat tree as the most
important structure. Sorry if I'm too lazy to back that up with hard data,
because that's not really the main point here.
- Ville Oikarinen
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
...
> > There are many general purpose data representations you could have
> > chosen: trees, lists, tables, graphs, ... But for some subjective
> > reason you prefer trees. Many people working for example with financial
> > data would prefer tables.
>
> Sure. There are different data structures. And there are lots of choices
> for the base structure that can be used to express the others.
>
> For example a table is easily represented as a tree:
>
> table {
> column {
> row {...}
> row {...}
> }
> ...
> }
In Lisp it would be
((1 2 3)
(a b c))
or direct
#2A((1 2 3) (a b c))
That's all trivial.
The first interesting thing is when you have
a graph.
For example you have three cities Hamburg, Hannover and Bremen.
From Hamburg you can reach Hannover and Bremen.
From Hannover you can reach Hamburg.
From Bremen you can reach Hamburg.
You can write that as a table. But one may want to
write it as a graph.
With Common Lisp it looks like this:
CL-USER> *cities*
(#1=(HAMBURG #2=(BREMEN #1#) #3=(HANNOVER #1#)) #2# #3#)
>
> Yes, it is a subjective choice to treat tree as the fundamental and most
> "natural" structure for representing data. In fact, computers probably
> would choose array... :)
>
> Anyway, even if I was the only person that wanted trees, you can probably
> still evaluate how well s-expressions suit _my_ needs, right?
Sure, but you seem to have understood the message: S-expressions
are list-like external data representations. If you want
to represent other data representations with S-expressions
you have to define a mapping.
>
> Besides, I don't think I'm so excpetional when I treat tree as the most
> important structure. Sorry if I'm too lazy to back that up with hard data,
> because that's not really the main point here.
There are many people in all those camps.
>
> - Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710161544380.9142@ttleush>
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
> Besides, I don't think I'm so excpetional when I treat tree as the most
> important structure. Sorry if I'm too lazy to back that up with hard data,
> because that's not really the main point here.
Thats not important, even hardly relevant. But I'm actually very
interested in _why_ you think the tree is the most important structure?
I also wonder why you don't think s-expressions are very suited for
representing trees? Do you think the following syntax would be
better:
{a (b c d)
{e (f g h)}
(i j k)}
?
In the syntax above, { and } represents the start and end of trees (where
the first elements (a and e) are the names of the trees), while
( and ) represents the start and end of lists. Or is this syntax missing
something?
On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
> Thats not important, even hardly relevant. But I'm actually very
> interested in _why_ you think the tree is the most important structure?
I admit one general error I detect in my own thinking and of the thinking
of lots of people is that we tend to eagerly force things into category
hierarchies. Taxonomies and other trees can be found everywhere. In object
oriented programming a very common beginner design mistake is to overuse
inheritance where delegation would be work better.
(One common hierarchy that restricts our thinking is the filesystem: why
do we either have to remember the one and only path to a file (ok, we have
symbolic links and mount magic) or search for the file? Other solutions
have been researched but they haven't got enough momentum (yet.)
However, I think tree itself is not the problem there. We get problems
when we stick to one tree at a time instead of using several hierarchies
flexibly.
This is speculation, I'm not that aware of my thinking in this regard, but
I suspect the fundamental role of tree in my thinking has something to do
with the fact the it doesn't feel natural to think without a context. Of
course a directed graph is a more accurate structure for associative
thinking, but the difference between graphs and trees isn't so radical,
especially if the tools support cycles and tree reuse. (So what looks like
a tree at the syntax level can actually be a graph for the tool.)
Anyway, I'm not prepared to discuss this very deeply, because I havent'
thought about it so much.
> I also wonder why you don't think s-expressions are very suited for
> representing trees? Do you think the following syntax would be
> better:
>
> {a (b c d)
> {e (f g h)}
> (i j k)}
>
> ?
>
> In the syntax above, { and } represents the start and end of trees (where
> the first elements (a and e) are the names of the trees), while
> ( and ) represents the start and end of lists. Or is this syntax missing
> something?
No, that doesn't look better. The syntax is not missing anything, I think
it has too much (the {} around the tree).
Besides, what is the relation between (b c d) and {e (f g h)}?
Are they both children of a? Then why are they in different collections?
- Ville Oikarinen
On Wed, 17 Oct 2007, Ville Oikarinen wrote:
>> I also wonder why you don't think s-expressions are very suited for
>> representing trees? Do you think the following syntax would be
>> better:
>>
>> {a (b c d)
>> {e (f g h)}
>> (i j k)}
>>
>> ?
>>
>> In the syntax above, { and } represents the start and end of trees (where
>> the first elements (a and e) are the names of the trees), while
>> ( and ) represents the start and end of lists. Or is this syntax missing
>> something?
>
> No, that doesn't look better. The syntax is not missing anything, I think
> it has too much (the {} around the tree).
>
Exactly, but I thought you wanted different kind of syntax for trees and
lists?
> Besides, what is the relation between (b c d) and {e (f g h)}?
>
> Are they both children of a?
>
Yes, the tree named "a" has three children: (b c d), {e (f g h)}
and (i j k).
* (b c d) is an anonymous list
* {e (f g h)} is a tree named "e" with one child: the anonymous list (f g h).
* (i j k) is another anonymous list
Isn't this what you wanted?
> Then why are they in different collections?
Collections of what?
On Wed, 17 Oct 2007, Kjetil S. Matheussen wrote:
> > No, that doesn't look better. The syntax is not missing anything, I think
> > it has too much (the {} around the tree).
> >
>
> Exactly, but I thought you wanted different kind of syntax for trees and
> lists?
Not really. I want a syntax that represents trees "well" and "naturally"
(defined elsewhere :-).
In fact, ideally the syntax for lists and trees would be as similar as
possible.
> Yes, the tree named "a" has three children: (b c d), {e (f g h)}
> and (i j k).
>
> * (b c d) is an anonymous list
> * {e (f g h)} is a tree named "e" with one child: the anonymous list (f g h).
> * (i j k) is another anonymous list
Oh, I see. I thought (b c d) was the child list of a. But it's just one
child.
The current ngr parser accepts empty symbols so the same could be written
as
a {
{b c d}
e {f g h}
{i j k}
}
(The first child of a has an empty symbol and children b, c and d.)
But I'm not sure if those empty symbols cause more confusion than they are
worth. My hypothesis is that in domain-specific modeling every thing
should have an explicit name. So maybe later I will make the parser fail
with the above input. I don't know yet. On the other some kind of support
is needed for empty strings, too.
- Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <Pine.LNX.4.64.0710181453590.9097@ttleush>
On Thu, 18 Oct 2007, Ville Oikarinen wrote:
>
>
> On Wed, 17 Oct 2007, Kjetil S. Matheussen wrote:
>
>>> No, that doesn't look better. The syntax is not missing anything, I think
>>> it has too much (the {} around the tree).
>>>
>>
>> Exactly, but I thought you wanted different kind of syntax for trees and
>> lists?
>
> Not really. I want a syntax that represents trees "well" and "naturally"
> (defined elsewhere :-).
>
I have read all your post, and yes, I see your smiley, but I still
don't think you have any rational arguments. Your problem is simply
that you haven't used lisp enough to know that its probably impossible to
to represent trees in textual form better than what can be done
with s-expressions.
The only problem I know of using s-expression for representing trees is
when strict memory usage is and issue, and/or you need O(1) access to
the leafs. But in those cases you can use structs or arrays as well
as s-expressions to build up your tree with.
On Thu, 18 Oct 2007, Kjetil S. Matheussen wrote:
> >> Exactly, but I thought you wanted different kind of syntax for trees and
> >> lists?
> >
> > Not really. I want a syntax that represents trees "well" and "naturally"
> > (defined elsewhere :-).
> >
>
> I have read all your post, and yes, I see your smiley, but I still don't
> think you have any rational arguments.
My whole perspective is that of a domain-specific language creator and
user. A "conceptual mismatch with trees" is not a technical argument.
With practice the mismatch is even easily ignorable. (Even too easily,
since it has required a lot of discussion to even get people to say aloud
that s-expressions are lists and not trees (modulo the implementation that
is neither).)
(And I have written an s-expression parser in Java and created many DSLs
with it, and I have also learned to write and interprete s-expressions as
trees, so this is not about my inability to do the interpretation.)
But non-technical or even subjective does not mean irrational.
If a syntax is to be used as a base for domain-specific languages, it is
its users that determine how well it works. For parsers there are no
"good" or "natural" syntaxes. Syntaxes are designed for humans.
Let's turn the question around. S-epxressions are in many ways the best
_general_ _purpose_ syntax there is, so there must be a good reason why it
is used so little. If it's not the reason I speculated, what do you
others think?
For example, why do people use XML? Clearly s-expressions are a superior
syntax, and there is a superior language backing it up. They have even
existed much longer than XML so it's not about legacy either.
Is it really irrational to assume that it's because whenever people think
something as a tree, they complain about the list vs tree mismatch, even
though they say it's about the parentheses? What other significant
difference is there really between "a (b c)" and "(a b c)" than the
_position_ of the parentheses?
Besides, parentheses are written outside in many contexts (like in normal
text like this). And in mathematics, denotating lists (vectors) and sets.
Why is it that they are only complained about in s-expressions?
As a notation, what difference is there between a mathematical list and an
s-expression list other than the fact that the mathematical list can
safely be interpreted as a list?
Is it irrational to assume that the notation for mathematical list/set is
not criticized about parentheses just because the notation doesn't require
an interpretation as tree?
Well, this pretty much starts to feel like a summary, so I'll see if there
are really some unexplored subtopics left. Thank you people for the debate
so far :)
> Your problem is simply that you haven't used lisp enough to know that
> its probably impossible to to represent trees in textual form better
> than what can be done with s-expressions.
Yes, but I have used s-expressions enough to _suspect_ this, even though I
wasn't sure.
- Ville Oikarinen
From: Kjetil S. Matheussen
Subject: Re: Then why do people dislike s-expressions (and talk about parentheses)?
Date:
Message-ID: <Pine.LNX.4.64.0710181559320.9097@ttleush>
On Thu, 18 Oct 2007, Ville Oikarinen wrote:
>
>
> On Thu, 18 Oct 2007, Kjetil S. Matheussen wrote:
>
>>>> Exactly, but I thought you wanted different kind of syntax for trees and
>>>> lists?
>>>
>>> Not really. I want a syntax that represents trees "well" and "naturally"
>>> (defined elsewhere :-).
>>>
>>
>> I have read all your post, and yes, I see your smiley, but I still don't
>> think you have any rational arguments.
>
> My whole perspective is that of a domain-specific language creator and
> user. A "conceptual mismatch with trees" is not a technical argument.
>
> With practice the mismatch is even easily ignorable. (Even too easily,
> since it has required a lot of discussion to even get people to say aloud
> that s-expressions are lists and not trees (modulo the implementation that
> is neither).)
>
> (And I have written an s-expression parser in Java and created many DSLs
> with it, and I have also learned to write and interprete s-expressions as
> trees, so this is not about my inability to do the interpretation.)
>
> But non-technical or even subjective does not mean irrational.
Nah, I don't quite agree about that. If anyone said that a(b,c) is
better than (a b c), because the first one looks better or is more
familiar, I would say thats an irrational argument. The reason is
that (a b c) is easier to parse and manipulate by a computer,
plus that the human soon get used to the (a b c) format and
after a while will find it just as easy or hard to read than
a(b,c) . (many who are familiar with (a b c) even thinks that
it looks much better than a(b,c) , and I agree about that,
and I think its because (a b c) is symmetric than a(b,c).)
At least, this is what I ment, when I said "non-rational",
it might very well have been a bad choice of word.
>
> If a syntax is to be used as a base for domain-specific languages, it is
> its users that determine how well it works. For parsers there are no
> "good" or "natural" syntaxes. Syntaxes are designed for humans.
>
> Let's turn the question around. S-epxressions are in many ways the best
> _general_ _purpose_ syntax there is, so there must be a good reason why it
> is used so little. If it's not the reason I speculated, what do you
> others think?
>
What do you base that its "used so little" on? Now you are getting back
to uninformed arguments again.
> For example, why do people use XML? Clearly s-expressions are a superior
> syntax, and there is a superior language backing it up. They have even
> existed much longer than XML so it's not about legacy either.
>
In XML, you don't have to use "'s around strings. Thats a great advantage
over s-expressions in many situations.
On Thu, 18 Oct 2007, Kjetil S. Matheussen wrote:
> > For example, why do people use XML? Clearly s-expressions are a superior
> > syntax, and there is a superior language backing it up. They have even
> > existed much longer than XML so it's not about legacy either.
> >
>
> In XML, you don't have to use "'s around strings. Thats a great advantage
> over s-expressions in many situations.
Yes, but s-expressions can be used in a way you don't need to make a
distinction between symbols and strings. Like this:
(paragraph
This is just normal text without any quotes)
- Ville Oikarinen
On Oct 19, 5:28 am, Ville Oikarinen <·····@oikarinen.org> wrote:
>
> Yes, but s-expressions can be used in a way you don't need to make a
> distinction between symbols and strings. Like this:
>
> (paragraph
> This is just normal text without any quotes)
>
I think this demonstrates part of your problem. You can (try) to use
s-exprs that way, and it has been done (interlisp, for instance, used
to say (COMMENT THIS IS A COMMENT) in at least some versions I think,
and later ones used (?) used, I think, * for this: (* "This is a
comment") (where * is actually IL:*, not CL:*).
But you have to consider what happens with something like (p this is a
(silly) example). Chances are you you aren't getting what you
expect. So, it turns out that you need some kind of way of deciding
what is markup and what is text. You could do this with a syntax
which allowed the string "(foo bar baz)" to read as the s-expression
(foo "bar baz"), but although that syntax would look like s-
expressions it actually would not be.
One interesting aside is that, if you've ever tried to type
substantial amounts of text marked up with *ML you'll discover that,
even with the requirements for quotes, it's easier to type stuff as s-
expressions (of course, editor support helps). That says something
incredibly bad about *XML as a syntax. I wrote a fairly substantial
manual using this. Later on, we moved to a very optimised syntax,
known as TML, which looked like
<p|body of the paragraph <ref :to ...|with a reference>>
--tim
From: Richard M Kreuter
Subject: Re: Then why do people dislike s-expressions (and talk about parentheses)?
Date:
Message-ID: <8764139hv0.fsf@progn.net>
Tim Bradshaw <··········@tfeb.org> writes:
> One interesting aside is that, if you've ever tried to type
> substantial amounts of text marked up with *ML you'll discover that,
> even with the requirements for quotes, it's easier to type stuff as
> s- expressions (of course, editor support helps). That says
> something incredibly bad about *XML as a syntax. I wrote a fairly
> substantial manual using this. Later on, we moved to a very
> optimised syntax, known as TML, which looked like
>
> <p|body of the paragraph <ref :to ...|with a reference>>
Maybe you're only talking about XML derivatives, but SGML actually let
you do something similar to this out of the box (i.e., without
recourse to a custom SGML declaration):
$ cat doc.sgml
<!DOCTYPE doc [
<!ELEMENT doc o o (p+)>
<!ELEMENT p - o ((#PCDATA|ref)*)>
<!ELEMENT ref - o (#PCDATA)>
<!ATTLIST ref to CDATA #REQUIRED>
]>
<p/body of the paragraph <ref to=somebody/with a reference//
$ nsgmls doc.sgml
(DOC
(P
-body of the paragraph
ATO CDATA somebody
(REF
-with a reference
)REF
)P
)DOC
C
(The final line is nsgmls's way of saying that this is a valid SGML
document instance, and the intervening output is a representation of
the document tree that's a sort of line-oriented sexpr notation, if
you squint a bit. Of course you might opine that it's a lose to have
the forward slash both end the start tag and end the element. It
might not possible to get an SGML processor to parse your exact
syntax, though.)
Of course, SGML's syntactic flexibility here doesn't end up being
terribly useful, for reasons that might be recognizable to Lispers:
the farther one gets from the fully normalized reference syntax, the
less applicable supporting tools such as editors become; and
tree-to-tree transformations become less likely to preserve the source
document's surface syntax, so if the generated trees are ever to be
looked at or hand-edited in their own right, the user has to be
comfortable with the fully normalized reference syntax anyhow.
--
RmK
On Oct 20, 12:13 am, verec <·····@mac.com> wrote:
>
> (table
> (column
> (row ...)
> (row ...)))
>
> ???
>
> WTF? :-)
Remember, in these kinds of discussions, that you must under no
circumstances read things as you normally would. Of *course* anyone
slightly literate reads *either* of the above as
TABLE ...
COLUMN ...
ROW ...
ROW ...
But you have, instead, to carefully avoid all the normal processing
you'd do and read them as if you'd never seen writing before. So
obsess about the positions of the punctuation characters, because
that's the kind of thing people who can't read worry about.
In other newsgroups you'll find people who complain that the bible has
way too many sentences beginning with "and". (And somewhere, they're
muttering that "Bible" should have a capital "B").
On Tue, 16 Oct 2007 11:21:22 +0000, Ville Oikarinen wrote:
> On Tue, 16 Oct 2007, Kjetil S. Matheussen wrote:
>
>> > "S-expressions are fine, but as a base for domain specific languages
>> > they have one flaw: they are not a natural match for trees.
>>
>> S-expression is a very natural match for trees since s-expressions
>> consists of cells having one pointer to a sub three (car), and one
>> pointer to the next leaf (cdr).
>
> No, that is a natural match for a linked list. A tree isn't like that.
> (Sure, s-expressions and linked lists are a clever implementation for
> trees, but conceptually they differ quite a lot.)
There are all sorts of trees. Lisp lists can be thought of as
ordered, rooted, binary trees in which only leaves are labeled (or
non-root nodes are all labeled ., which is what prolog does. It's
a handy way to think about them when implementing algorithms that treat
trees as strings over ranked alphabets).
Now, if you want to represent an ordered binary tree that can have other
labels, one way to do it is (label left-child . right-child) (or, making
the structure more clear (label . (left-child . right-child)) )*. For
ordered, labeled trees in general, you can represent any as a binary
tree whose left child is it's leftmost child and whose right is it's
rightmost sibling; proof is in just about every data structure book.
If you want unordered or unrooted trees, well, you're going to have to
make them ordered and just disregard order, but you'll have to do that in
any language. If you want unrooted trees, you can represent them using
one of the data structures for a graphs. Common Lisp even has builtin
functions for association lists.
So, excluding infinite trees, I'm not seeing any tree that can't be
represented as a list in lisp. You could do infinite trees too, you'd
just have to implement lazy evaluation. Peter Norvig's book can tell you
how.
From: Klaus Schilling
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <87lk9o61oz.fsf@web.de>
"Kjetil S. Matheussen" <··············@notam02.no> writes:
>
> The reason s-expressions sometimes gets critique is because lispers
> often claim that s-expressions are simple and beautiful.
those who deny the simplicity and beauty of S-Expressions are pervies
Klaus Schilling
In article <··································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> Hello.
>
> Please don't ignore this post as "just another rant about lisp
> parentheses", but read on. This may not be new, but at least I try to
> recognize both the merits and problems of s-expressions :)
>
> I already touched this question last may in this group, but I'd like to
> hear more what you lispers think of it.
>
> So the question is: Could it be that people who feel uncomfortable with
> lisp parentheses just can't express themselves clearly: it's not the
> parentheses per se but the way they are used that bothers them.
>
> Here is the problem (published yesterday at
> http://ngrease.sourceforge.net/introduction.html#Lispdialects):
>
> "S-expressions are fine,
Does it matter if S-Expressions are 'fine'? What makes them 'fine'?
> but as a base for domain specific languages they
> have one flaw: they are not a natural match for trees.
What means 'natural' in this context?
> An s-expression is
> either a childless singular or an anonymous list.
of s-expressions.
> A tree
What kind of 'tree'? What do you want to represent?
> is generally
> represented as an anonymous list, whose first element is _interpreted_ as
> the root and the rest are _interpreted_ as the children. Not only is the
> mapping to the conceptual tree indirect, but when inspected closely, the
> actual language has poor _semantic density:_ 50% of it consists of
> anonymous lists."
What problem do you solve? Show examples. We'll
tell you then what Lisp solutions look like.
This would be a typical s-expression describing
a robot-arm (example taken from Genworks website,
http://www.genworks.com/downloads/gdl-doc/gdl-tutorial.pdf ).
(define-object robot-arm (base-object)
:input-slots
(side
shoulder-point
angle
pincer-distance)
:computed-slots
((display-controls (list :color :blue)))
:objects
((arm :type 'box)
(thumb :type 'box
:display-controls (list :color :red)
:width (the :hand :width)
:height (the :hand :height)
:length (the :hand :length)
:center (translate (the :hand :center)
(the :side) (the :pincer-distance)))
(hand :type 'box
:display-controls (list :color :green)
:center (translate (the :center) :down
(+ (half (the :height))
(half (the-child :height)))
(the :side)
(- (- (half (the :width))
(half (the-child :width)))))
:height (* (the :height) 0.15)
:width (* (the :width) 0.2)
:length (half (the :length)))))
What kind of problems do you see?
I'd really prefer if we can talk about real examples
and not about non-applicable concepts like 'natural'
or 'fine'.
On Tue, 16 Oct 2007, Rainer Joswig wrote:
> > "S-expressions are fine,
>
> Does it matter if S-Expressions are 'fine'? What makes them 'fine'?
I explained this later in my post by giving an example of what they are
good at. Compared to bloated syntaxes (like C, Java, ...) they are more
than fine.
> > but as a base for domain specific languages they
> > have one flaw: they are not a natural match for trees.
>
> What means 'natural' in this context?
I explained this, too. Maybe you started typing your answer before reading
the whole text? :)
> > An s-expression is
> > either a childless singular or an anonymous list.
>
> of s-expressions.
>
> > A tree
>
> What kind of 'tree'? What do you want to represent?
Any kind. Tree is a very fundamental structure for presenting virtually
anything.
> What problem do you solve? Show examples. We'll
> tell you then what Lisp solutions look like.
I know what s-expressions look like. I have experimented with scheme so I
have some feeling of what functional programming is about. But this topic
is not about actual programming. It's about representing data (be it
"code" or not).
> (hand :type 'box
> :display-controls (list :color :green)
> :center (translate (the :center) :down
> (+ (half (the :height))
> (half (the-child :height)))
> (the :side)
> (- (- (half (the :width))
> (half (the-child :width)))))
> :height (* (the :height) 0.15)
> :width (* (the :width) 0.2)
> :length (half (the :length)))))
>
>
> What kind of problems do you see?
Conceptually this describes a hand that has attributes. One of the
attributes is type (:type in lisp) with value box ('box in lisp). The
required colon and quote are just minor noise and not the point.
Conceptually an attribute belongs "inside" or "below" the concept it
describes, doesn't it? But this relationship isn't directly present in the
above s-expression. It needs some _interpretation_ to make sense.
The structure is just one big list. The first subexpression (number 0),
hand, is _interpreted_ as the root concept. Then subexpressions 1+(2*n)
are _interpreted_ as attribute keys and subexpressions 2+(2*n) as
attribute values.
As an m-expression the hand could be described like this, for example:
hand (
:type ('box)
...
)
In ngr I would write it (removing lisp-specific colons and single quotes)
as
hand {
type:box
display-controls: color:green
center: $:translate... #:"some code"
...
}
(I won't describe the actual code, because like I said, this topic is not
about the code.)
In xml it would be something like this:
<hand>
<type>box</type>
<display-controls>
<color>green</color>
</display-controls>
<!-- Here I will describe code even less, because XML and code -->
<!-- don't work together -->
</hand>
or something.
In all these examples there are no anonymous lists that require some
special interpretation. The conceptual hierarchy (attributes inside a
concept) maps one-to-one to the data structure.
- Ville Oikarinen
> In all these examples there are no anonymous lists that require some
> special interpretation. The conceptual hierarchy (attributes inside a
> concept) maps one-to-one to the data structure.
What if we define a list in the form (car . cdr) as a -named- list
whose name is car? Then magically anonymous lists in need of
interpretation simply disappear :)
Further, what if we decide that, in a form like the one above, the cdr
must be considered as being conceptually "inside" or "below" the
concept the car describes?
As you can see, by making the appropriate assumptions there's really
no formal distinction between, say, s-expressions and xml (or ngr I
suppose, but I don't know ngr enough to be sure). Please note that,
when dealing with xml or ngr, you implicitly make your own load of
assumptions (e.g. that <something>contents</something> describes an
object of type something and contents describe such object's
properties).
S-expressions are used not because they're the best way to represent
trees. Instead, the reason of their success (yes, success) is that
they're one of the simplest ways to represent trees, *and* (this is
what is truly important) they can be manipulated by simple primitives
like car, cdr, cons, etc. Try writing a macro system for xml. Then
compare it with the Common Lisp macro system. Then, perhaps, you'll
understand what we like about s-expressions.
cheers
Alessio Stalla
On Tue, 16 Oct 2007, Alessio wrote:
> > In all these examples there are no anonymous lists that require some
> > special interpretation. The conceptual hierarchy (attributes inside a
> > concept) maps one-to-one to the data structure.
>
> What if we define a list in the form (car . cdr) as a -named- list
> whose name is car? Then magically anonymous lists in need of
> interpretation simply disappear :)
Yes, that's what needs to be done. Still, the syntax really looks like a
list of things inside parentheses. Besides, this general interpretation
can't be made, because in other contexts the elements inside the list
really are siblings.
So _sometimes_ the first element is the parent and at other times it's
not.
> S-expressions are used not because they're the best way to represent
> trees. Instead, the reason of their success (yes, success) is that
> they're one of the simplest ways to represent trees, *and* (this is
> what is truly important) they can be manipulated by simple primitives
> like car, cdr, cons, etc. Try writing a macro system for xml. Then
> compare it with the Common Lisp macro system. Then, perhaps, you'll
> understand what we like about s-expressions.
Yes, I understand what we (including me) like about s-expressions. I'm
disappointed that I obviously didn't make this clear enough while
discussing what they don't work optimally for.
- Ville Oikarinen
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Rainer Joswig wrote:
>
> > > "S-expressions are fine,
> >
> > Does it matter if S-Expressions are 'fine'? What makes them 'fine'?
>
> I explained this later in my post by giving an example of what they are
> good at. Compared to bloated syntaxes (like C, Java, ...) they are more
> than fine.
'bloated' and 'fine' are not well-defined concepts when we
talk about data representation.
> > What means 'natural' in this context?
>
> I explained this, too. Maybe you started typing your answer before reading
> the whole text? :)
Where do you define 'natural'. What is 'natural' for you in
this context?
>
> > > An s-expression is
> > > either a childless singular or an anonymous list.
> >
> > of s-expressions.
> >
> > > A tree
> >
> > What kind of 'tree'? What do you want to represent?
>
> Any kind. Tree is a very fundamental structure for presenting virtually
> anything.
Hmm...
> > What problem do you solve? Show examples. We'll
> > tell you then what Lisp solutions look like.
>
> I know what s-expressions look like. I have experimented with scheme so I
> have some feeling of what functional programming is about. But this topic
> is not about actual programming. It's about representing data (be it
> "code" or not).
Right, that is also what I am talking about.
>
> > (hand :type 'box
> > :display-controls (list :color :green)
> > :center (translate (the :center) :down
> > (+ (half (the :height))
> > (half (the-child :height)))
> > (the :side)
> > (- (- (half (the :width))
> > (half (the-child :width)))))
> > :height (* (the :height) 0.15)
> > :width (* (the :width) 0.2)
> > :length (half (the :length)))))
> >
> >
> > What kind of problems do you see?
>
> Conceptually this describes a hand that has attributes. One of the
> attributes is type (:type in lisp) with value box ('box in lisp). The
> required colon and quote are just minor noise and not the point.
>
> Conceptually an attribute belongs "inside" or "below" the concept it
> describes, doesn't it? But this relationship isn't directly present in the
> above s-expression. It needs some _interpretation_ to make sense.
Every external representation needs 'interpretation'. Lisp
has its definition of the external syntax (which is not fixed,
but programmable). "foo" is a string. |foo| is a symbol,
123 is an integer, 1.23 is a float, () is an empty list, and so
on.
In this case we use the primitive idea of lists. Plus we take
the freedom that different list elements or list positions
can be interpreted differently. Lisp notation uses lists
either to directly mean data-structures like lists or sets,
or it means a sequence of things. The latter makes no
commitment on the list level what it means. The interpretation
is given by some program.
S-expressions are just lists of lists or other data.
How you want to use it to externally represent trees, graphs, tables,
dictionaries, sets, is up to you. You don't have to. You
can use other external representations. There are some conventions
that have been developed over time and some of these conventions
are also supported directly by Lisp (assoc lists, property lists,
cyclic lists, ...).
With Lisp lists you actually don't want to make
more commitments how you use it later. For example
you could transform the lists or create
object representations. There might be special
datastructures for it, or more processing is
needed to determine the right ones.
The step one is just to read it.
Welcome to OpenMCL Version 1.1-pre-070512 (DarwinX8664)!
? (read)
(hand :type 'box
:display-controls (list :color :green)
:center (translate (the :center) :down
(+ (half (the :height))
(half (the-child :height)))
(the :side)
(- (- (half (the :width))
(half (the-child :width)))))
:height (* (the :height) 0.15)
:width (* (the :width) 0.2)
:length (half (the :length)))
(HAND :TYPE 'BOX :DISPLAY-CONTROLS (LIST :COLOR :GREEN) :CENTER
(TRANSLATE (THE :CENTER) :DOWN (+ (HALF (THE :HEIGHT)) (HALF (THE-CHILD
:HEIGHT))) (THE :SIDE) (- (- (HALF (THE :WIDTH)) (HALF (THE-CHILD
:WIDTH))))) :HEIGHT (* (THE :HEIGHT) 0.15) :WIDTH (* (THE :WIDTH) 0.2)
:LENGTH (HALF (THE :LENGTH)))
The usual thing is to have a objects or structures
to be created from those simple descriptions:
? (defstruct hand
type display-controls center height width length)
? (apply #'make-hand *)
#S(HAND :TYPE 'BOX :DISPLAY-CONTROLS (LIST :COLOR :GREEN) :CENTER
(TRANSLATE (THE :CENTER) :DOWN (+ (HALF (THE :HEIGHT)) (HALF (THE-CHILD
:HEIGHT))) (THE :SIDE) (- (- (HALF (THE :WIDTH)) (HALF (THE-CHILD
:WIDTH))))) :HEIGHT (* (THE :HEIGHT) 0.15) :WIDTH (* (THE :WIDTH) 0.2)
:LENGTH (HALF (THE :LENGTH)))
The structure has an external representation that includes
the used data-structure name (the structure HAND in this case).
You can use it just like lists, but if you read it back you get a
structure and the external representation uses a special (fixed)
syntax to encode the structure name and the key-value-pairs.
>
> The structure is just one big list. The first subexpression (number 0),
> hand, is _interpreted_ as the root concept. Then subexpressions 1+(2*n)
> are _interpreted_ as attribute keys and subexpressions 2+(2*n) as
> attribute values.
>
> As an m-expression the hand could be described like this, for example:
>
> hand (
> :type ('box)
> ...
> )
>
> In ngr I would write it (removing lisp-specific colons and single quotes)
> as
>
> hand {
> type:box
> display-controls: color:green
> center: $:translate... #:"some code"
> ...
> }
>
> (I won't describe the actual code, because like I said, this topic is not
> about the code.)
>
> In xml it would be something like this:
>
> <hand>
> <type>box</type>
> <display-controls>
> <color>green</color>
> </display-controls>
> <!-- Here I will describe code even less, because XML and code -->
> <!-- don't work together -->
> </hand>
>
> or something.
>
> In all these examples there are no anonymous lists that require some
> special interpretation. The conceptual hierarchy (attributes inside a
> concept) maps one-to-one to the data structure.
Which data-structure does XML use?
>
> - Ville Oikarinen
On Tue, 16 Oct 2007, Rainer Joswig wrote:
> 'bloated' and 'fine' are not well-defined concepts when we
> talk about data representation.
If you don't know what I mean by bloated when I compare Java syntax to
Lisp syntax, let's forget that subject then. We have other more relevant
points to discuss.
> In this case we use the primitive idea of lists. Plus we take
> the freedom that different list elements or list positions
> can be interpreted differently. Lisp notation uses lists
> either to directly mean data-structures like lists or sets,
> or it means a sequence of things. The latter makes no
> commitment on the list level what it means. The interpretation
> is given by some program.
> ...
The point I got from your explanation was that there is one general data
structure, list, and a well-defined set of list operations provides a tool
for operating on different kinds of "things".
Yes, that's the power of s-expressions. Unified data structure and all
that.
But what I don't see is how the other syntaxes I presented (especially the
ngrease data structure) won't have this same advantage? It also has a
unified data structure while communicating the domain-specific tree more
directly.
> Which data-structure does XML use?
A terrible one. I just pointed out that regardless of its problems, XML is
also a direct match for trees while s-expression is not.
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o0bqazhxy2.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> On Tue, 16 Oct 2007, Rainer Joswig wrote:
>
>> In this case we use the primitive idea of lists. Plus we take
>> the freedom that different list elements or list positions
>> can be interpreted differently. Lisp notation uses lists
>> either to directly mean data-structures like lists or sets,
>> or it means a sequence of things. The latter makes no
>> commitment on the list level what it means. The interpretation
>> is given by some program.
>> ...
>
> The point I got from your explanation was that there is one general data
> structure, list, and a well-defined set of list operations provides a tool
> for operating on different kinds of "things".
As Rainer answered, this is true, but it's also important to
understand (as I know you do) and to bring into discussion (as has
been implied elsewhere) that the list data type is not the only
structure in lisp, but it is the structure underlying the
s-expression. I prefer to call this structure by its more formal
name, the cons, so that there is no unfair weighting toward lists
where trees are also fully representable by these "list" elements.
> Yes, that's the power of s-expressions. Unified data structure and all
> that.
And not only unified, but versatile and fully mapped as well. By
versatile I mean that a variety of structures can be represented by
groups of cons cells, and by fully mapped I mean that the textual
representation of lists and trees can be recreated from each other -
i.e. from the printed representation one can build the structure in a
lisp environment, and from the structure one can recreate a printed
representation.
Note that the mapping is not one-to-one, and the shortcuts do lean
toward the most-used form of s-expr, the list; for example, the
representation of (a . (b . nil)) is a relatively flat tree that can
be also represented as (a b)
Elsewhere in this thread, you also noted that the first in the list
was given special significance, and you implied that that was unfair,
or perhaps better represented by e.g. a(b,c) rather than (a b c).
However, the s-expression simply models real life in this aspect; how
often in any ordered list of equals do you _not_ find that the first
one is treated specially? Examples: first to finish in a race;
extended priveleges for firtborn among siblings; first to apply for a
patent; ...
But in reality, it is not the s-expression's syntax that gives the
precedence to the first in the list; it is the _convention_ when Lisp
is dealing with code to take the first in the list as operator, and
the rest as arguments.
> But what I don't see is how the other syntaxes I presented (especially the
> ngrease data structure) won't have this same advantage? It also has a
> unified data structure while communicating the domain-specific tree more
> directly.
>
>> Which data-structure does XML use?
>
> A terrible one. I just pointed out that regardless of its problems, XML is
> also a direct match for trees while s-expression is not.
I don't agree with the latter portion of this statement; and I believe
others have also responded to this.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Tue, 16 Oct 2007, Duane Rettig wrote:
> Elsewhere in this thread, you also noted that the first in the list
> was given special significance, and you implied that that was unfair,
> or perhaps better represented by e.g. a(b,c) rather than (a b c).
> However, the s-expression simply models real life in this aspect; how
> often in any ordered list of equals do you _not_ find that the first
> one is treated specially? Examples: first to finish in a race;
> extended priveleges for firtborn among siblings; first to apply for a
> patent; ...
Isn't that a little far-fetched? That a list magically turns into a tree
when (this is not always the case) there is a "special" role for the first
element? That yonger siblings somehow belong _below_ the first-born in the
family-tree? :)
Besides, a common but not universal "rule" like that must not be used as
an argument in designing general solutions.
> But in reality, it is not the s-expression's syntax that gives the
> precedence to the first in the list; it is the _convention_ when Lisp
> is dealing with code to take the first in the list as operator, and
> the rest as arguments.
Yes, of course. My whole point is that such a convention is needed, and
it's not needed in syntaxes that have been designed for trees.
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o08x61snau.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> On Tue, 16 Oct 2007, Duane Rettig wrote:
>
>> Elsewhere in this thread, you also noted that the first in the list
>> was given special significance, and you implied that that was unfair,
>> or perhaps better represented by e.g. a(b,c) rather than (a b c).
>> However, the s-expression simply models real life in this aspect; how
>> often in any ordered list of equals do you _not_ find that the first
>> one is treated specially? Examples: first to finish in a race;
>> extended priveleges for firtborn among siblings; first to apply for a
>> patent; ...
>
> Isn't that a little far-fetched? That a list magically turns into a tree
> when (this is not always the case) there is a "special" role for the first
> element? That yonger siblings somehow belong _below_ the first-born in the
> family-tree? :)
No, that's not what I'm saying. I'm saying that given s-expressions,
the mapping that Lisp tends to place on them that treats them like
lists, but not necessarily treating the elements as equal siblings
[sic], is quite a natural mapping. But such a mapping has nothing to
do with trees (well, it's arguable, but Lispers tend not to look at an
s-expression which looks like a function call as if it were a tree).
> Besides, a common but not universal "rule" like that must not be used as
> an argument in designing general solutions.
>
>> But in reality, it is not the s-expression's syntax that gives the
>> precedence to the first in the list; it is the _convention_ when Lisp
>> is dealing with code to take the first in the list as operator, and
>> the rest as arguments.
>
> Yes, of course. My whole point is that such a convention is needed, and
> it's not needed in syntaxes that have been designed for trees.
Given what you said here:
| > Thats not important, even hardly relevant. But I'm actually very
| > interested in _why_ you think the tree is the most important structure?
|
| I admit one general error I detect in my own thinking and of the thinking
| of lots of people is that we tend to eagerly force things into category
| hierarchies. Taxonomies and other trees can be found everywhere. In object
| oriented programming a very common beginner design mistake is to overuse
| inheritance where delegation would be work better.
... do you still hold to your argument that such a convention is
needed? If so, why trees? Why not allow the s-expression to be
interpreted in whatever format the domain-specific language is best
designed for, which may not be tree-oriented?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Wed, 17 Oct 2007, Duane Rettig wrote:
> Given what you said here:
>
> | > Thats not important, even hardly relevant. But I'm actually very
> | > interested in _why_ you think the tree is the most important structure?
> |
> | I admit one general error I detect in my own thinking and of the thinking
> | of lots of people is that we tend to eagerly force things into category
> | hierarchies. Taxonomies and other trees can be found everywhere. In object
> | oriented programming a very common beginner design mistake is to overuse
> | inheritance where delegation would be work better.
>
> ... do you still hold to your argument that such a convention is
> needed? If so, why trees? Why not allow the s-expression to be
> interpreted in whatever format the domain-specific language is best
> designed for, which may not be tree-oriented?
Yes, I still hold to my argument. _When_ tree is what's wanted, ngr works
better than s-expression.
Whenever (anonymous) lists express the intent better, s-expression works
better.
The question of when a tree expresses a given intent better than a list is
more subjective, and I don't believe I have an answer for that. Like I
wrote earlier, I have just a vague feeling of the reasons why I feel trees
express many things better than lists, but I'm not prepared to discuss
them analytically (yet).
- Ville Oikarinen
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Duane Rettig wrote:
>
> > Elsewhere in this thread, you also noted that the first in the list
> > was given special significance, and you implied that that was unfair,
> > or perhaps better represented by e.g. a(b,c) rather than (a b c).
> > However, the s-expression simply models real life in this aspect; how
> > often in any ordered list of equals do you _not_ find that the first
> > one is treated specially? Examples: first to finish in a race;
> > extended priveleges for firtborn among siblings; first to apply for a
> > patent; ...
>
> Isn't that a little far-fetched? That a list magically turns into a tree
> when (this is not always the case) there is a "special" role for the first
> element? That yonger siblings somehow belong _below_ the first-born in the
> family-tree? :)
>
> Besides, a common but not universal "rule" like that must not be used as
> an argument in designing general solutions.
>
> > But in reality, it is not the s-expression's syntax that gives the
> > precedence to the first in the list; it is the _convention_ when Lisp
> > is dealing with code to take the first in the list as operator, and
> > the rest as arguments.
>
> Yes, of course. My whole point is that such a convention is needed, and
> it's not needed in syntaxes that have been designed for trees.
Sure. Lisp's S-Expressions are more primitive. They are a
simple format to write down nested lists and that notation can be adopted
to many purposes.
S-Expressions for example don't have a schema definition
like you have in XML. If the S-expression is well-formed
based on the s-expression syntax
that's enough - there is by default no mechanism that
describes or constraints the contents of s-expressions.
Those things (a grammar definition, a procedural interpretation,
a pattern-based interpretation, ...) have to be developed
on top. All those have been developed in Lisp over the
years - for all those you can find examples.
You can easily see that where those tools are available (in Lisp),
the notation is widely used. Where the tools are not available
or have some kind of cognitive mismatch, the notation has
not been a success.
If you want to use s-expressions as a notation, then you
may need a grammar formalism to describe and check
the s-expressions. In Lisp often there is some
simple check done by the Lisp system when you
pass an s-expression as an argument to a function,
a macro or to a MAKE-INSTANCE call. The lack
of a grammar for some macro expressions is sometimes
a pain - there I would also think that a simple
grammar would be useful, since it enables a simple
check of the contents of the S-expressions.
For example there is a platform independent way
to describe windows and its contents. Developers
write those descriptions as s-expressions as part
of a macro call. Unfortunately every implementation
has a slightly different interpretation and
slightly different extensions to it. There it
would make sense to define the description format
in a way, that the window description can be checked
for standard conformance.
>
> - Ville Oikarinen
On Wed, 17 Oct 2007, Rainer Joswig wrote:
> S-Expressions for example don't have a schema definition
> like you have in XML. If the S-expression is well-formed
> based on the s-expression syntax
> that's enough - there is by default no mechanism that
> describes or constraints the contents of s-expressions.
Or maybe it would be more correct to say that generally where
s-expressions are used, no meta-models (schemas) are used.
It would be perfectly possible to use a meta-model based solution with
s-expressions. The trivial example is to use XML with some parser that
consumes s-expressions and produces XML DOMs. This way you can define both
the documents and their meta-models using s-expressions.
I have this same "problem" in the ngrease language, too. It is even more
dynamic (typeless and meta-modelless) than lisps.
- Ville Oikarinen
From: Pascal Costanza
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <5nm6npFihpjfU1@mid.individual.net>
Ville Oikarinen wrote:
>
> On Wed, 17 Oct 2007, Rainer Joswig wrote:
>
>> S-Expressions for example don't have a schema definition
>> like you have in XML. If the S-expression is well-formed
>> based on the s-expression syntax
>> that's enough - there is by default no mechanism that
>> describes or constraints the contents of s-expressions.
>
> Or maybe it would be more correct to say that generally where
> s-expressions are used, no meta-models (schemas) are used.
Not quite: Our meta-models are called macros.
A good macro usually performs checks whether the s-expressions passed to
it are well-formed, and issues errors and warnings if they are not. At
the same time, it also performs the model transformation by generating
code in an underlying, simpler language.
Some Scheme macro systems (like syntax-rules and syntax-case) also have
a high-level destructuring language which gives a more declarative way
of expressing what are valid, well-formed invocations of the respective
macros.
Some Lisp macros don't even generate Lisp code in the end. For example,
some of the Lisp-based markup language generate HTML, PDF, etc.
Common Lisp has a well-defined notion of macroexpansion time, which is
specified to be at compile time in compiled code. So the checks that
macros perform are completely static (and should be static even for
interpreted code, to ensure portability).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <··············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> Ville Oikarinen wrote:
> >
> > On Wed, 17 Oct 2007, Rainer Joswig wrote:
> >
> >> S-Expressions for example don't have a schema definition
> >> like you have in XML. If the S-expression is well-formed
> >> based on the s-expression syntax
> >> that's enough - there is by default no mechanism that
> >> describes or constraints the contents of s-expressions.
> >
> > Or maybe it would be more correct to say that generally where
> > s-expressions are used, no meta-models (schemas) are used.
>
> Not quite: Our meta-models are called macros.
>
> A good macro usually performs checks whether the s-expressions passed to
> it are well-formed, and issues errors and warnings if they are not. At
> the same time, it also performs the model transformation by generating
> code in an underlying, simpler language.
Many macros only do it for the top-level part of the s-expression
(the part that is defined in the macro argument list)
and sometimes obscure errors will be presented.
Checking well-formedness of the S-expression is often poorly
done. A typical thing that plagues CLIM users is the
clim:define-application-frame macro that has extremely
poor checking of its baroque syntax in most implementations
I have seen.
>
> Some Scheme macro systems (like syntax-rules and syntax-case) also have
> a high-level destructuring language which gives a more declarative way
> of expressing what are valid, well-formed invocations of the respective
> macros.
>
> Some Lisp macros don't even generate Lisp code in the end. For example,
> some of the Lisp-based markup language generate HTML, PDF, etc.
>
> Common Lisp has a well-defined notion of macroexpansion time, which is
> specified to be at compile time in compiled code. So the checks that
> macros perform are completely static (and should be static even for
> interpreted code, to ensure portability).
>
>
> Pascal
On Wed, 17 Oct 2007, Pascal Costanza wrote:
> > Or maybe it would be more correct to say that generally where
> > s-expressions are used, no meta-models (schemas) are used.
>
> Not quite: Our meta-models are called macros.
Yes, in a sense this is true. I have also discussed this with a haskell
user: a transformer that refuses to produce illegal code (illegal in some
sense that type systems generally prevent) is a kind of static type
system, or metamodel, even if the underlying language is dynamically typed
(like lisp) or typeless (like ngrease).
But, AFAIK, what these kinds of metamodels generally lack is being a help
to editors. For example XML editors can suggest legal content with the
help of a metamodel (schema). Are there any editors that can do this with
lisp macros?
So ngrease transformers and lisp macros, when written well, can give
similar guarantees (not necessarily proven guarantees but anyway) than a
type system, but I guess more research is needed to make these type
systems act more proactively (during editing) instead of just giving
errors during the compile or run phase.
Some day I hope to be able to derive ngrease transformers and metamodels
needed by clever editors from a common source.
- Ville Oikarinen
From: Pascal Costanza
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <5nona3Fj9cagU2@mid.individual.net>
Ville Oikarinen wrote:
>
> On Wed, 17 Oct 2007, Pascal Costanza wrote:
>
>>> Or maybe it would be more correct to say that generally where
>>> s-expressions are used, no meta-models (schemas) are used.
>> Not quite: Our meta-models are called macros.
>
> Yes, in a sense this is true. I have also discussed this with a haskell
> user: a transformer that refuses to produce illegal code (illegal in some
> sense that type systems generally prevent) is a kind of static type
> system, or metamodel, even if the underlying language is dynamically typed
> (like lisp) or typeless (like ngrease).
>
> But, AFAIK, what these kinds of metamodels generally lack is being a help
> to editors. For example XML editors can suggest legal content with the
> help of a metamodel (schema). Are there any editors that can do this with
> lisp macros?
Yes, of course. They cannot easily suggest the types of macro arguments,
because there are no static types in the general case, but they can, and
do, suggest how many parameters are expected and what the parameter
names in the macro definitions are. That's already very helpful.
That's for Common Lisp development environments. (My experience stems
mostly from LispWorks, but other CL environments do this as well.) I
guess that Scheme environments can probably do even more, due to the
pattern matching in syntax-rules and syntax-case, but I have no hands-on
experience in that regard. You may want to ask at comp.lang.scheme for
more information here...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Ville Oikarinen wrote:
>> Which data-structure does XML use?
>
> A terrible one. I just pointed out that regardless of its problems, XML is
> also a direct match for trees while s-expression is not.
>
> - Ville Oikarinen
> <hand>
> <type>box</type>
> <display-controls>
> <color>green</color>
> </display-controls>
> <!-- Here I will describe code even less, because XML and code -->
> <!-- don't work together -->
> </hand>
(:hand
(:type 'box)
(:display-controls
(:color 'green)))
How is this not a direct match for trees as compared to xml ?
Sacha
In article <···································@localhost>,
Ville Oikarinen <·····@oikarinen.org> wrote:
> On Tue, 16 Oct 2007, Rainer Joswig wrote:
>
> > 'bloated' and 'fine' are not well-defined concepts when we
> > talk about data representation.
>
> If you don't know what I mean by bloated when I compare Java syntax to
> Lisp syntax, let's forget that subject then. We have other more relevant
> points to discuss.
No, you don't understand syntax in (Common) Lisp. That's all.
It is a bit different, but you can also say it is bloated.
* first you have a syntax for data: lists, symbols, number, ...
That already includes thing like complex numbers,
symbols with packages, circular lists, arrays
with dimensions, structures, ...
I haven't counted, but there are a lot data structures
with external representations in Common Lisp.
* on top of that there is another layer of syntax,
provided by special forms, macros, and possibly more
To give an example. Check out the Hyperspec for DEFSTRUCT.
This is the syntax:
defstruct name-and-options [documentation] {slot-description}*
=> structure-name
name-and-options::= structure-name | (structure-name [[options]])
options::= conc-name-option |
{constructor-option}* |
copier-option |
include-option |
initial-offset-option |
named-option |
predicate-option |
printer-option |
type-option
conc-name-option::= :conc-name | (:conc-name) | (:conc-name conc-name)
constructor-option::= :constructor |
(:constructor) |
(:constructor constructor-name) |
(:constructor constructor-name
constructor-arglist)
copier-option::= :copier | (:copier) | (:copier copier-name)
predicate-option::= :predicate | (:predicate) | (:predicate
predicate-name)
include-option::= (:include included-structure-name {slot-description}*)
printer-option::= print-object-option | print-function-option
print-object-option::= (:print-object printer-name) | (:print-object)
print-function-option::= (:print-function printer-name) |
(:print-function)
type-option::= (:type type)
named-option::= :named
initial-offset-option::= (:initial-offset initial-offset)
slot-description::= slot-name |
(slot-name [slot-initform [[slot-option]]])
slot-option::= :type slot-type |
:read-only slot-read-only-p
Common Lisp has lots of syntax like that.
>
> > In this case we use the primitive idea of lists. Plus we take
> > the freedom that different list elements or list positions
> > can be interpreted differently. Lisp notation uses lists
> > either to directly mean data-structures like lists or sets,
> > or it means a sequence of things. The latter makes no
> > commitment on the list level what it means. The interpretation
> > is given by some program.
> > ...
>
> The point I got from your explanation was that there is one general data
> structure, list, and a well-defined set of list operations provides a tool
> for operating on different kinds of "things".
Right.
> Yes, that's the power of s-expressions. Unified data structure and all
> that.
>
> But what I don't see is how the other syntaxes I presented (especially the
> ngrease data structure) won't have this same advantage? It also has a
> unified data structure while communicating the domain-specific tree more
> directly.
Right, that's fine.
In Lisp you have
* S-expressions, where the parentheses enclose the 'things'.
Which for example makes certain editing operations easy.
* An editor like emacs has commands to manipulate the textual
structure (transpose, move up, ...)
* READ takes an external representation and internalizes it
* PRINT prints it
* EVAL tries to interpret it as code
* PPRINT is a simple (extensible) formatter
* plus there are lots of functions to manipulate or create
internalized S-expressions
>
> > Which data-structure does XML use?
>
> A terrible one. I just pointed out that regardless of its problems, XML is
> also a direct match for trees
XML makes no commitment to a data-stucture. It is not a programming
language, that provides you with an internal representation.
XML is JUST external. XML parsers may use any kind of data structure
for internalized XML text data.
> while s-expression is not.
All you need to do for S-expressions is to define how trees
should be externally represented using S-expressions. That's all.
For example you can say:
* the empty list is the empty tree
* the first object of a list gives the name of the node element-type
* the rest of the list is a property list of node attribute names and
values
* attribute values can be trees (or other data like symbols)
Then you are done.
> - Ville Oikarinen
Ville Oikarinen <·····@oikarinen.org> writes:
> On Tue, 16 Oct 2007, Rainer Joswig wrote:
> > > but as a base for domain specific languages they
> > > have one flaw: they are not a natural match for trees.
> >
> > What means 'natural' in this context?
>
> I explained this, too. Maybe you started typing your answer before reading
> the whole text? :)
I don't think that you are taking on board the full
difficulty of the task that you are undertaking. The
original text says:
"S-expressions are fine, but as a base for domain specific languages they
have one flaw: they are not a natural match for trees. An s-expression is
either a childless singular or an anonymous list. A tree is generally
represented as an anonymous list, whose first element is _interpreted_ as
the root and the rest are _interpreted_ as the children. Not only is the
mapping to the conceptual tree indirect, but when inspected closely, the
actual language has poor _semantic density:_ 50% of it consists of
anonymous lists."
Let me start by picking out one sentence
An s-expression is either a childless singular or an
anonymous list.
This is good and true and the first and most direct way of
looking at s-expressions, but as Bill Clinton said: it
depends what the meaning of `is' is. Two meanings are at
issue here
Exhaustive
----------
When we claim that A is B we intend to justify a strong form
such that we can disprove A is C simply by pointing out: no,
A is B
Informative
-----------
When we claim that A is B we intend to justify a weak form
which we will use for backward chaining. Need B? Then use
A. This will work because A is B. Need C? We haven't said
whether A is C and usable here also.
I see four things in play. Two concepts, first the nested-list, which
comprises either a childless singular or an anonymous
nested-list, and second the tree, with a singular label on
each node and zero or more children. Two realisations, the
s-expression, and the t-expression, where the t-expression
is a putative natural way of typing in a tree.
The quoted text goes from s-expression to
nest-list.
We are much more interested in going from tree to a
realisation of the concept. We want to know what
t-expressions look like and why we should consider them to
be natural. Nor is this idle curiousity.
Let us type in a tree in an over-explicit way and go in
search of the natural t-expression
(node-label a
child-zero (node-label b
child-zero c
child-one d)
child-one (node-label e)
child-two (node-label f
child-zero (node-label g
child-zero h)))
How about
(a (b c d)
(e)
(f (g h)))
We are in a sense seeing `(a', `(b', `(e', `(f', and `(g' as
node-labels. Perhaps that is not a natural way of writing a
tree, but what do we mean by natural and how do we know?
The argument that it cannot represent a tree because it
is an s-expression and s-expressions represent singulars and
anonymous lists does not persuade because no argument is
given that representation is a function rather than a
relation.
Alan Crowe
Edinburgh
Scotland
On Tue, 16 Oct 2007, Alan Crowe wrote:
> Let me start by picking out one sentence
>
> An s-expression is either a childless singular or an
> anonymous list.
>
> This is good and true and the first and most direct way of
> looking at s-expressions, but as Bill Clinton said: it
> depends what the meaning of `is' is. Two meanings are at
> issue here
>
> Exhaustive
> ----------
> When we claim that A is B we intend to justify a strong form
> such that we can disprove A is C simply by pointing out: no,
> A is B
My sentence is not meant as an exhaustive definition. I'm only comparing
s-expressions and ngr as concrete syntaxes.
> The argument that it cannot represent a tree because it
> is an s-expression and s-expressions represent singulars and
> anonymous lists does not persuade because no argument is
> given that representation is a function rather than a
> relation.
I haven't said that s-expressions cannot represent a tree. They can.
(It's surprising how much I need to say "I haven't said that" and "Yes,
that's what I have been saying" in this thread. Is it so difficult to stay
cool when somebody is brave and foolish enough to say that some part of
lisp is not quite perfect in some context?)
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o0wstlr779.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> I haven't said that s-expressions cannot represent a tree. They can.
>
> (It's surprising how much I need to say "I haven't said that" and "Yes,
> that's what I have been saying" in this thread. Is it so difficult to stay
> cool when somebody is brave and foolish enough to say that some part of
> lisp is not quite perfect in some context?)
I think the reason we get this impression is due to a couple of your
postings, in which you imply not that an s-expression cannot represent
a tree, but that it is somehow less able to do so.
Two examples:
1. [said of m-expressions, ngr, and XML syntax:]
| All these other syntaxes are quite suitable for expressing trees. Is this
| the reason they are more "acceptable" for the masses?
2.
| But what I don't see is how the other syntaxes I presented (especially the
| ngrease data structure) won't have this same advantage? It also has a
| unified data structure while communicating the domain-specific tree more
| directly.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Kent M Pitman
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <umyuhpzki.fsf@nhplace.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> (It's surprising how much I need to say "I haven't said that" and "Yes,
> that's what I have been saying" in this thread. Is it so difficult to stay
> cool when somebody is brave and foolish enough to say that some part of
> lisp is not quite perfect in some context?)
Your wording suggests that people have not stayed cool, yet I think they have.
I don't put much stock in your observation not because there isn't a reason
that some might dislike it for this reason. I'm sure there is.
If you go back and re-read Alan's message to which you're replying, it
contained some lucid points about how language works, in particular
that there are several meanings to wordings and you're using some wording
that is confusing on its face.
I don't have time to do a lot of detail this morning, so I'll just cite a
quick example for you to ponder. In your initial post, you write
"Could this be the reason why people dislike s-expressions".
I would hardly think your post noteworthy if you'd used the word "a"
instead of "the". There are many reasons people who choose to dislike
Lisp feel as they do. This could be one of them. But the entire
meaning of your statement changes when you use the word "the" because
it asks the question "the dominant reason". It presupposes that the
reasons to dislike a language are somehow canonical and convergent,
and that we should be searching for a single, unified, all-explanatory
thing.
The truth is that there are many things people do and don't like Lisp and
I don't see anyone denying the statement "There exists an x such that
x dislikes lisp because of <your reason>." Nor even "a number of x's".
The dominant reason why I don't think what you're saying is true of
most people is that I frankly don't think most people use trees. They
study them in school, but in my career I've not seen that to be the
dominant data structure, ESPECIALLY in languages like C/C++/etc. which
have had had measurably more programmer seats. Trees aren't a hard
concept, but they aren't used much and they aren't advocated as the
reason to use Lisp. Lisp is not Treep. It's "List Processing". And
we do ok at lists.
I agree there are some rough edges about trees, but there are in most
languages. And I just think it's in the noise with respect to why Lisp
is or is not accepted.
You can choose to regard my disagreeing with y ou as my losing my cool,
but in doing so you will entirely miss my point.
I don't have any problem acknowledging that Lisp's tree structure does
not primitively satisfy every kind of tree--it's an objective truth that
trees are often taught as ternary structures (two children and a node point)
and we don't have a primitive type for that, so you end up making it out
of two things. I just don't think the fact of that is a huge deal.
Indeed, there have been Lisps that did have these things [Maclisp had
hunks and CDC lisp had ternary conses]. The features were useful, and
were used, but were not sufficiently used that anyone minded when they
went away and were replaced by something more general: structs, which
solved other problems. So I doubt the claim on that basis as well.
A stronger criticism of Lisp would be its lack of native data structure
for a midi file or a jpg. Programmers would care a lot more about that.
But fortunately, that can be accommodated, too. And trees are not the
enabling structure to bridge that gap, incidentally.
I did find your observation interesting as "one person's opinion", btw.
And I thank you for sharing it. I just don't think it's representative
of The (as in the sense that the definite article is used) problem.
As a meta-proposition, a pluralistic world rarely has so crisp a
singleton problem.
On Wed, 17 Oct 2007, Kent M Pitman wrote:
> Ville Oikarinen <·····@oikarinen.org> writes:
>
> > (It's surprising how much I need to say "I haven't said that" and "Yes,
> > that's what I have been saying" in this thread. Is it so difficult to stay
> > cool when somebody is brave and foolish enough to say that some part of
> > lisp is not quite perfect in some context?)
>
> Your wording suggests that people have not stayed cool, yet I think they have.
I hope my wording didn't sound too hot-headed when my intention was just
to say "please keep cool and read what I said and don't extrapolate so I
don't need to repeat everything" and "treat my arguments as such and don't
bundle them with earlier arguments (from the latest 50 years or so) about
the topic".
I assumed the reason was that the topic (dislike of parentheses etc) is so
frequently discussed that people kind of "see red" and start to reiterate
old discussion that IMHO haven't included my arguments. And that
discussion (at least in c.l.l) is often quite heated, ad hominem etc...
But if this wasn't the case and the misunderstandings were just caused by
my ambiguous and misleading wording in the original post, I'm releaved.
Because that I can fix by further explanation.
> I don't have time to do a lot of detail this morning, so I'll just cite a
> quick example for you to ponder. In your initial post, you write
> "Could this be the reason why people dislike s-expressions".
>
> I would hardly think your post noteworthy if you'd used the word "a"
> instead of "the". There are many reasons people who choose to dislike
> Lisp feel as they do. This could be one of them. But the entire
> meaning of your statement changes when you use the word "the" because
> it asks the question "the dominant reason". It presupposes that the
> reasons to dislike a language are somehow canonical and convergent,
> and that we should be searching for a single, unified, all-explanatory
> thing.
>
> The truth is that there are many things people do and don't like Lisp and
> I don't see anyone denying the statement "There exists an x such that
> x dislikes lisp because of <your reason>." Nor even "a number of x's".
Ok, my question is still whether it's "the" reason (meaning the most
important of them). But a discussion of the reason as "a" reason is
welcome, too.
> The dominant reason why I don't think what you're saying is true of
> most people is that I frankly don't think most people use trees. They
> study them in school, but in my career I've not seen that to be the
> dominant data structure, ESPECIALLY in languages like C/C++/etc. which
> have had had measurably more programmer seats. Trees aren't a hard
> concept, but they aren't used much and they aren't advocated as the
> reason to use Lisp. Lisp is not Treep. It's "List Processing". And
> we do ok at lists.
Maybe I haven't explained my point of view: it's about domain-specific
languages, not "actual" programming i.e. low-level implementation.
I guess you are thinking trees as a techical tool. Yes, as such they are
not used very much, for example compared to lists.
But in domain-specific modeling I think trees are "the" data structure.
Hence the "the" in my question.
And yes, lisp is about lists, and should be. I'm not interested in what
things are "inside" a language. For my domain-specific modeling needs I
just want to be able to _express_ trees "naturally" (again, defined
elsewhere :-).
> You can choose to regard my disagreeing with y ou as my losing my cool,
> but in doing so you will entirely miss my point.
No, I hope I didn't give the impression of accusing of that whenever
somebody disagrees with me :)
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o0d4vcsbl4.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> On Wed, 17 Oct 2007, Kent M Pitman wrote:
>
>> The dominant reason why I don't think what you're saying is true of
>> most people is that I frankly don't think most people use trees. They
>> study them in school, but in my career I've not seen that to be the
>> dominant data structure, ESPECIALLY in languages like C/C++/etc. which
>> have had had measurably more programmer seats. Trees aren't a hard
>> concept, but they aren't used much and they aren't advocated as the
>> reason to use Lisp. Lisp is not Treep. It's "List Processing". And
>> we do ok at lists.
>
> Maybe I haven't explained my point of view: it's about domain-specific
> languages, not "actual" programming i.e. low-level implementation.
>
> I guess you are thinking trees as a techical tool. Yes, as such they are
> not used very much, for example compared to lists.
>
> But in domain-specific modeling I think trees are "the" data structure.
> Hence the "the" in my question.
>
> And yes, lisp is about lists, and should be. I'm not interested in what
> things are "inside" a language. For my domain-specific modeling needs I
> just want to be able to _express_ trees "naturally" (again, defined
> elsewhere :-).
I think I now know why you've been hitting your head against a wall in
this group. You talk about domain-specific modelling and speak as if
we know nothing of the term. But domain-specific modelling (and the
domain-specific languages that form the basis of it) are the staple
diet of Lispers; it is the major area where Lisp shines. Lisp has in
fact been touted as the programming-language programming language, and
domain-specific languages are the example given that prove the point.
Consider the various CAD systems, some 20 to 30 years old, that use a
defpart/defassembly style of modelling; yes, they are tree oriented,
and YES, they use s-expressions to represent those trees! These trees
are not anonymous, and although they can be printed in any form, they
are inevitably provided as source in s-expression form (whether they
get sucked up internally as trees of conses or as trees of structs).
Also, elsewhere you stated that there was a consencus about
s-expressions being inferior as tree representations; Tim placed
himself on the other side of that concensus, and I now do also - in
reality, I don't think you have a concensus (unless it's a concensus
of 1 :-)
So I think in order to make your argument here without becoming
frustrated you must qualify what specific domain-specific languages
you're dabbling in, and why you think that s-expressions are inferior
for _those_ specific DSLs/DSMs.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Thu, 18 Oct 2007, Duane Rettig wrote:
> I think I now know why you've been hitting your head against a wall in
> this group. You talk about domain-specific modelling and speak as if we
> know nothing of the term.
If I gave that impression, it was completely accidental. Of course I know
the role lisp has had in DSL creation for decades.
The more I have to wonder _why_ XML was ever even born let alone got so
popular.
- Ville Oikarinen
From: Duane Rettig
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <o0przbaspq.fsf@gemini.franz.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> On Thu, 18 Oct 2007, Duane Rettig wrote:
>
>> I think I now know why you've been hitting your head against a wall in
>> this group. You talk about domain-specific modelling and speak as if we
>> know nothing of the term.
>
> If I gave that impression, it was completely accidental. Of course I know
> the role lisp has had in DSL creation for decades.
>
> The more I have to wonder _why_ XML was ever even born let alone got so
> popular.
Because it wasn't Lisp. When the AI Winter hit mid-90s, AI had lost
companies billions of dollars in research money because the AI hype
had predicted returns on investment that were overly optimistic to the
tune of at least twice as long (e.g. 10 years rather than 5 years).
AI became a hated name, and Lisp became the scapegoat as the language
of choice of AI. When during that time I would show people an example
of EDIF files, they would tend to screw up their noses and say "looks
like lisp, to me". End of conversation. My theory is that XML is
successful because it does a good job of getting close to Lisp-like
without _looking_ like Lisp.
In other words, to the extent that a manager (or even a techie)
equates AI to Lisp, and Lisp to parentheses, it is not a hard leap for
some to make that parentheses spell money lost. An incorrect leap,
but an easy one nonetheless.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: Richard M Kreuter
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <871wbr9bv4.fsf@progn.net>
Duane Rettig <·····@franz.com> writes:
> Ville Oikarinen <·····@oikarinen.org> writes:
>> The more I have to wonder _why_ XML was ever even born let alone
>> got so popular.
>
> Because it wasn't Lisp. When the AI Winter hit mid-90s, AI had lost
> companies billions of dollars in research money because the AI hype
> had predicted returns on investment that were overly optimistic to
> the tune of at least twice as long (e.g. 10 years rather than 5
> years). AI became a hated name, and Lisp became the scapegoat as
> the language of choice of AI. When during that time I would show
> people an example of EDIF files, they would tend to screw up their
> noses and say "looks like lisp, to me". End of conversation. My
> theory is that XML is successful because it does a good job of
> getting close to Lisp-like without _looking_ like Lisp.
>
> In other words, to the extent that a manager (or even a techie)
> equates AI to Lisp, and Lisp to parentheses, it is not a hard leap for
> some to make that parentheses spell money lost. An incorrect leap,
> but an easy one nonetheless.
I somehow doubt that not looking like Lisp was a design goal, even if
looking like Lisp would have been a poison pill. XML wasn't initially
an attempt to find the optimal interchange format; it was the result
of W3C efforts to evolve a parseable subset of SGML for the world wide
web, so that people wouldn't need conforming SGML processors (which
nobody has ever had, AFAICT). That is, for people who were already
doing things with HTML or SGML, the upgrade path to XML was loosely
describable as "use the concrete reference syntax, close all elements,
and make sure things nest properly", which was already notionally good
hygiene anyhow. I think XML's current popularity is entirely
extrinsic, owing solely to the fact that web-related technologies have
dwarfed everything else in deployment; whatever had been settled on as
the easily-parsed encoding for the web would have become ubiquitous,
IMO.
--
RmK
From: =?utf-8?b?R2lzbGUgU8ODwqZsZW5zbWk=?= =?utf-8?b?bmRl?=
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <0nzlyb75dv.fsf@kaktus.ii.uib.no>
Richard M Kreuter <·······@progn.net> writes:
> Duane Rettig <·····@franz.com> writes:
> > Ville Oikarinen <·····@oikarinen.org> writes:
>
> >> The more I have to wonder _why_ XML was ever even born let alone
> >> got so popular.
> >
> > Because it wasn't Lisp.
> > <snip>
>
> I somehow doubt that not looking like Lisp was a design goal, even if
> looking like Lisp would have been a poison pill.
I also doubt that Lisp was designed to not look like XML, and by knowing where
it came from, I'm almost sure. What I think Duane meant was not that XML was
designed to not be like lisp, but rather that it _succeded_ because it did not
resemble Lisp, which is two different things.
XML came from SGML that was designed mainly for text markup. When having some
infrequent tags in a text to tell the purpose of the different parts of it,
a good design may look very different from s-expressions. Now typical XML usage
is very different from what SGML was designed for, and some of these usages are
very similar to what s-expressions are used for in Lisp. That does not mean
that XML was designed to be s-expressions without parantheses, even though it
ended up that way.
--
Gisle Sælensminde, Phd student, Scientific programmer
Computational biology unit, BCCS, University of Bergen, Norway,
Email: ·····@cbu.uib.no
The best way to travel is by means of imagination
From: Tim X
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <87abqbvj7i.fsf@lion.rapttech.com.au>
Duane Rettig <·····@franz.com> writes:
> Ville Oikarinen <·····@oikarinen.org> writes:
>
>> On Thu, 18 Oct 2007, Duane Rettig wrote:
>>
>>> I think I now know why you've been hitting your head against a wall in
>>> this group. You talk about domain-specific modelling and speak as if we
>>> know nothing of the term.
>>
>> If I gave that impression, it was completely accidental. Of course I know
>> the role lisp has had in DSL creation for decades.
>>
>> The more I have to wonder _why_ XML was ever even born let alone got so
>> popular.
>
> Because it wasn't Lisp. When the AI Winter hit mid-90s, AI had lost
> companies billions of dollars in research money because the AI hype
> had predicted returns on investment that were overly optimistic to the
> tune of at least twice as long (e.g. 10 years rather than 5 years).
> AI became a hated name, and Lisp became the scapegoat as the language
> of choice of AI. When during that time I would show people an example
> of EDIF files, they would tend to screw up their noses and say "looks
> like lisp, to me". End of conversation. My theory is that XML is
> successful because it does a good job of getting close to Lisp-like
> without _looking_ like Lisp.
>
> In other words, to the extent that a manager (or even a techie)
> equates AI to Lisp, and Lisp to parentheses, it is not a hard leap for
> some to make that parentheses spell money lost. An incorrect leap,
> but an easy one nonetheless.
>
Unfortunately, I think there is some truth to that.
I also think it is partially due to the fact that for many people, XML was
one solution to the 'problems' people had encountered with HTML (and to a
lesser extent SGML) combined with a general scary ignorance regarding what
I had once thought were basic concepts and theories that any programmer
would have. Those who recognised the similarity in structure between XML
and s-expressions and were able to appreciate the benefits that would come
from using s-experessions also knew it would be a very difficult job to
sell it as too many would see it as being too close to lisp. However, there
is also a really really large group of people out there who have no idea
what s-expressions are and who see XML as just being a 'well formed'
version of HTML (often they don't even know what SGML is). For this group,
XML is a 'natural' extension that is superior to the data as HTML world
they have grown up in (their programming has been essentially web based
using Java, VB, PHP and maybe some perl). To this group, XML is an amazing
development as it makes parsing almost trivial compared to what they have
had to do with HTML. For them, XML is familiar and fits with their model of
things.
The other point is that by creating hype over XML, you could also sell
yourself as an XML expert, which sounds a bit more impressive to many
consultants/managers than trying to sell yourself as an expert with lisp or
s-expressions. It sounds new, so it must be better (I still hear people
criticise perfectly good software on the basis it is written in lisp, which
is 'old' and therefore cannot be as good as something written in a language
that is 'new').
This is not unusual. Much of what we see as 'new' advances often looks
remarkably like something from the past, just with a new coat of paint. A
colleague of mine reckons its all like hem lines - they go up and they go
down, but they are always there. Others would probably just talk about
swings and round-a-bouts. While it is true that s-expressions may have some
advantages over XML in some applications, the reality is that most of the
time, XML is being used in a way that the additional benefits of
s-expressions are unlikely to be seen as a benefit.
Tim
--
tcross (at) rapttech dot com dot au
From: Kent M Pitman
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <ufy08o121.fsf@nhplace.com>
Ville Oikarinen <·····@oikarinen.org> writes:
> But in domain-specific modeling I think trees are "the" data structure.
> Hence the "the" in my question.
Yet in such a domain, I would probably not even think to use lists.
Just as an example, my XML implementation uses (standard) classes, not
lists. Or in other situations I'd use structs. I would ony use lists
if the natural structure of things, and the set of operations available,
seemed to make lists the natural choice.
That is, my process is NOT this (which I admit is often the taught process,
but which is often not what I want, and perhaps is the reason I use Lisp):
NOT MY ALGORITHM
A. Analyze the problem, see that it needs trees.
B. Find the tool that has "Keywords: trees" in its documentation.
Assume that its having advertised itself as a "trees" tool in
its marketing literature makes it perfect for my needs.
C. Use the tool blindly.
D. Be outraged when it seems not what I want and I find that I have
stupidly used an unabstracted operation throughout my code and now have
a high cost of changing it.
Rather, the process I use is more evolutionary:
A. Make a list of the operations I need.
B. Abstract out the data and function representations, such that it makes
no difference how I implement it. Grab easy-to-use abstractions and
just don't fuss over whether they're right until it matters, refining
the highly-localized implementation as needed during later use.
C. Program for a while and see what happens.
In my world, the fact that lists or hash tables or structures or whatever is
generally a highly local choice. I assume code is "refactored" (that's the
term-of-the-day, though the practice goes back eons) constantly, and that
tons of code goes away, so premature optimization is a multiplier on the
amount of code I'm throwing away and a cost drain.
If most of my code is the part at the front where I'm choosing data
structures, that means I have a TINY application. So if this choice
is capable of dominating my programming, the case where that happens
is in the noise.
The reason this is relevant is that I don't feel pigeon-holed by what
lists can and cannot do. They're just a tool. I build my own abstractions
out of primitive capabilities and abstraction tools; lisp has both of
those. I don't need a bunch of built-in abstractions, I need a bunch
of built-in abstraction tools. And I have that.
> And yes, lisp is about lists,
IMO, this is an enormously naive and myopic point of view.
To say that Lisp is about lists is like saying physics is about algebra.
Lists are a gool. Lisp, to the extent it is about anything, is about giving
programmers a playground in which to enjoy a development experience which
is interactive, adaptive, tolerant, etc... everything that is not true of
most other languages.
George Carrette used to (and perhaps still does--it's been a while
since we chatted on the matter) teach new users of Lisp how to program
without ever mentioning lists. When I heard this (which was probably
back in the early 1980's), he didn't even have to explain to me why,
nor apologize for the fact that it wasn't lists. It was immediately
obvious (a) what he was saying and (b) why it was an interesting
approach. Nor did it sound unLispy to me, nor I suspect to anyone with
a proper understanding of lists.
It may help to remember: we didn't name the language. The language
name has been little but baggage from the beginning. The best
successful variations on Lisp may have been enabled as much by their
decision to not use the name Lisp as by the chosen semantics--not
because a language is just its name, but because the change in name
allowed the language to evade compatibility baggage and allowed a
fresh design, and because the name meant that critics had to come up
with another criticism because the tired old jokes about lisp didn't
fly any more.
To wit (or lack thereof): Although as a matter of history, lisp means
list processing, the language has long ago grown far beyond that, and
we are burdened by people trying to analyze its nature by looking at
the etymology from 40+ (well, almost 50 now) years ago. We haven't
cast off the name, but we are not an unchanged community, and
analyzing our past is not analyzing our present. To the extent that
lists are important today, what I always teach about lisp is that
what's important is not that lists are the RIGHT data structure but
that the rightness of what Lisp did (it's not an absolute quantity,
just a subjective success that people can study the nature of) comes
more from its arbitrary willingness to say "let's pretend there's a
canonical choice in certain key areas so that there is a 'reasonable
default' people can assume absent other specification". It might be
very useful, for example, to talk about programs as arrays, not lists,
or trees as structs, not lists. But the power comes not from the
choice, but from its being a done deal, not to be argued about. All
is lost if you make a final choice and then argue.
> > You can choose to regard my disagreeing with y ou as my losing my cool,
> > but in doing so you will entirely miss my point.
>
> No, I hope I didn't give the impression of accusing of that whenever
> somebody disagrees with me :)
Your wording was taken as accusatory by people under quite normal rules of
how people interpret things. Perhaps you didn't intend that, but if you did
not, perhaps an analysis will help explain other interactions you might be
having in other forums we're not seeing that perhaps also baffle you. I'll
walk through an analysis because a lot of people, even though they know not
to do these things, often do not know why:
| Is it so difficult to stay
| cool when somebody is brave and foolish enough to say
In a sentence, the primary verb is often taken to establish a new relationship
among pre-existing facts.
"John is captain of the football team."
is not a statement about John, it presupposes John. If John does not
already exist, the sentence calls for you to accept that there is such
a person. This is not a statement about the football team. We are
assumed to presuppose one, and that it has a captain likewise. This
sentence is shorthand for:
"There exists a guy named John.
There exists a football team.
The football team has a captain.
John is that captain."
There is a syndrome in language often referred to as the "have you stopped
beating your wife?" question. The problem with that question is that it
admits no yes/no answer, even though it presents as one. To see why, let's
decompose it:
"There exists a person.
You are that person.
That person (you) has been beating his wife.
Have you stopped yet?"
Under this decomposition, you can see that if you got as far as the question,
to understand it, you've already set up the hypothetical that allows you to
understand it, and you have already gotten happily past the presupposition
of a premise that is (hopefully in most cases) absurd. It's the form of the
question that is objectionable, even before the answer.
Now let's return to your statement:
| Is it so difficult to stay
| cool when somebody is brave and foolish enough to say
I'll decompose the full range of things I hear when I hear this sentence:
"There is a statement x, which is <what you said>.
Saying x as unpopular.
Being unpopular, criticism or harm will come to anyone who utters it.
It is therefore dangerous to utter x.
It is easy to see the danger.
It is therefore obvious that uttering x brings on the danger.
Anyone who voluntarily takes on danger is a fool.
It is therefore foolish to bring on x.
x is true.
Saying truth is noble.
Anyone who knowingly takes on danger for nobility's sake is brave.
People will resist x and saying it will perhaps bring no good end.
Saying something that will change nothing but incurs danger is also foolish.
People objecting to rationality involves losing one's cool.
The passionate expression of differing opinion is best described as losing
one's cool.
If someone is passionate about something, they have lost their cool.
Losing one's cool is ipso facto a proof that there is no valid argument.
People lose their cool only grudgingly, hence if one loses his/her cool,
that's proof tat it's difficult to stay cool (i.e., no one is naturally
passionate)
When several people are passionate, that is ipso facto a proof that
it is difficult for these people to restrain themselves.
comp.lang.lisp is a representative sample of otherwise calm people.
The people who speak on comp.lang.lisp rather than just lurking are
representatives of the most normally calm souls.
A few people who normally speak on comp.lang.lisp disagreed.
Those people who spoke on comp.lang.lisp were passionate.
Having spoken passionately, they had lost their cool.
Other facts implied by context, not the sentece:
Ville knows x is true (people generally don't assert what they don't
believe true [Kenny notwithstanding])
Ville said x.
People were passionate in their replies.
Conclusions:
Ville is brave because he knows x is true and took
on knowing danger.
Ville is foolish because I know x is true, know it
will be resisted, know it's dangerous to say, and accept that
probably little will come of it.
People on comp.lang.lisp are unable to accept truth.
People on comp.lang.lisp are unable to control their displeasure
with the speaking of truth."
It sounds like you didn't mean all of the thing I heard in the sentence
you wrote, but if you understand what was heard, perhaps you can understand
why people called it flamebait. Whenever one jumps to a conclusion that
leaps past a number of controversial assumptions and appears to take them
as given, I predict similar outcomes for reasons quite like the above.
Please don't take any of the above as me putting words in your mouth.
None of my point was about your intent. My point was about the complexity
of language.
As a linguist myself, I see linguistic confusions among people (almost
all tv sitcoms are based on it) as both the thing that ever lets them get
along (when often they disagree on material points but don't realize it)
AND as the thing that causes all the problems (since often they think they
disagree on petty points that they do not). But mostly what I see is that
even native speakers of a language often don't realize that human language
is, not due to their training, but due to its complexity, something that
is really hard to be fluent in. The mere fact that people equate fluency
with "ability to correctly manage in all circumstances" is a major problem
because people often don't question the most likely source of problem.
At least competent drivers of cars know in their heart that even they (and
certainly people with less training) are still likely to make errors, and
are taught to "drive defensively" as a way of heading off the inevitable.
Learning to "speak defensively" would help for many people, if the word
defensive didn't already have another meaning in terms of interpersonal
conversational that is similar but has subtlely different, deprecating,
and hence self-defeating connnotations. Ah well.
Ville Oikarinen <·····@oikarinen.org> writes:
> > Exhaustive
> > ----------
> > When we claim that A is B we intend to justify a strong form
> > such that we can disprove A is C simply by pointing out: no,
> > A is B
>
> My sentence is not meant as an exhaustive definition. I'm only comparing
> s-expressions and ngr as concrete syntaxes.
You have to mean the exhaustive definition. It is essential
to the logic of your original post.
You have not directly argued that S-expressions do a bad job
of representing trees. You have argued indirectly, saying
that S-expressions do a good job of representing lists. So
to complete your argument you need a reason why
S-expressions cannot be good at both.
Pace Kent, my post was not about language but about logical
structure. The problem with saying "An S-expression is a
list" is not that it is ambiguous. The problem is that you
justify one of the two meanings, but the logic of your
argument depends on the other one. The ambiguity of natural
language is merely the camouflage on the trap.
Alan Crowe
Edinburgh
Scotland
From: John Thingstad
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <op.t0cqo9fppqzri1@pandora.upc.no>
P� Wed, 17 Oct 2007 18:54:38 +0200, skrev Alan Crowe
<····@cawtech.freeserve.co.uk>:
>
> Pace Kent, my post was not about language but about logical
> structure. The problem with saying "An S-expression is a
> list" is not that it is ambiguous. The problem is that you
> justify one of the two meanings, but the logic of your
> argument depends on the other one. The ambiguity of natural
> language is merely the camouflage on the trap.
>
Maybe I got it wrong, but I thought he said we have lists of lists. They
can be used to represent lists and are fine for some types of tree's but
not ideal for all. If I had a tree with a known 4 child nodes I would use
a array [1]. His point as I saw it was that this in itself didn't reflect
on lisp.
1. structure more likely, but they as classes, are implemented as arrays
(for structures unless otherwise spesified)
On Wed, 17 Oct 2007, Alan Crowe wrote:
> Ville Oikarinen <·····@oikarinen.org> writes:
>
> > > Exhaustive
> > > ----------
> > > When we claim that A is B we intend to justify a strong form
> > > such that we can disprove A is C simply by pointing out: no,
> > > A is B
> >
> > My sentence is not meant as an exhaustive definition. I'm only comparing
> > s-expressions and ngr as concrete syntaxes.
>
> You have to mean the exhaustive definition. It is essential
> to the logic of your original post.
On the syntax level, it is exhaustive. But it's not exhaustive in the
sense that Lisp _implements_ s-expressions as conses. In that sense
s-expression is also something else than lists.
> You have not directly argued that S-expressions do a bad job
> of representing trees. You have argued indirectly, saying
> that S-expressions do a good job of representing lists. So
> to complete your argument you need a reason why
> S-expressions cannot be good at both.
Yes, when discussing s-expressions as a syntax, I rely on the exhaustive
definition "s-expression is either a singular or an anonymous list".
- Ville Oikarinen
On Tue, 16 Oct 2007, Rainer Joswig wrote:
> > An s-expression is
> > either a childless singular or an anonymous list.
>
> of s-expressions.
By that you probably want to demonstrate that s-expressions are trees, as
they contain children of the same type as themselves?
And you are of course right. I need to clarify my point: the s-epxpression
_is_ a tree, but it's not the same tree its reader/writer thinks of.
(Generally.)
That's what I meant by saying that the semantic density is poor and half
of the structure consists of technical stuff irrelevant to the "payload"
tree, the actual domain-specific tree the s-expression tries to
communicate.
This family tree
(grand-father
(father
(me)
(my-brother))
(my-uncle
(my-cousin)))
is actually, when inspected more closely, like this (using the ngr
syntax):
anonymous-list {
grand-father
anonymous-list {
anonymous-list:me
anonymous-list:my-brother
}
anonymous-list {
anonymous-list:my-cousin
}
}
10 symbols, 6 of which are "anonymous-list", which has no meaning in the
domain of family trees.
- Ville Oikarinen
On Tue, 16 Oct 2007, Ville Oikarinen wrote:
> This family tree
>
> (grand-father
> (father
> (me)
> (my-brother))
> (my-uncle
> (my-cousin)))
>
Here's the corrected ngr conversion:
anonymous-list {
grand-father
anonymous-list {
father
anonymous-list:me
anonymous-list:my-brother
}
anonymous-list {
my-uncle
anonymous-list:my-cousin
}
}
12 symbols, 6 of which are out of the domain of family trees.
- Ville Oikarinen
> [...]
>
> 10 symbols, 6 of which are "anonymous-list", which has no meaning in the
> domain of family trees.
But, the same argument can be used when translating, e.g., from ngr to
s-expressions, for example I could decide to translate:
hand {
type:box
display-controls: color:green
center: $:translate... #:"some code"
...
}
to:
(ngr-object :name "hand" :attributes (list (:name "type" :value "box")
(:name "display-controls" :value (color :green)) (:name
"center" :translate <some code>) ...))
again, many symbols have no meaning in the domain of "hands". But,
this is an artifact of having used a very literal translation instead
of a more "natural" one (for some value of natural). imho of course...
AS
On Tue, 16 Oct 2007, Alessio wrote:
> But, the same argument can be used when translating, e.g., from ngr to
> s-expressions, for example I could decide to translate:
>
> hand {
> type:box
> display-controls: color:green
> center: $:translate... #:"some code"
> ...
> }
>
> to:
>
> (ngr-object :name "hand" :attributes (list (:name "type" :value "box")
> (:name "display-controls" :value (color :green)) (:name
> "center" :translate <some code>) ...))
>
> again, many symbols have no meaning in the domain of "hands". But,
> this is an artifact of having used a very literal translation instead
> of a more "natural" one (for some value of natural). imho of course...
Sure, the data structure itself is technical, and there s no way around
that. Programming languages are technical beasts. (See
http://ngrease.sourceforge.net/introduction.html#AnASTlibrary for a
description of the ngrease data structure.)
A more correct description of the above structure would be this, using the
ngr syntax:
element {
symbol:hand
children {
element {
symbol:type
children {
element {
symbol:box
children #:empty
}
}
}
...
}
}
But the difference here is that in the ngrease data structure the elements
inside a list are _always_ siblings. The first-born _always_ has the
privilege of being a child instead of playing parent for his siblings :-)
So no interpretation is needed to understand the domain-specific
hierarchy.
- Ville Oikarinen
From: Thomas A. Russ
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <ymilka23h3o.fsf@blackcat.isi.edu>
Ville Oikarinen <·····@oikarinen.org> writes:
> And you are of course right. I need to clarify my point: the s-epxpression
> _is_ a tree, but it's not the same tree its reader/writer thinks of.
> (Generally.)
>
> That's what I meant by saying that the semantic density is poor and half
> of the structure consists of technical stuff irrelevant to the "payload"
> tree, the actual domain-specific tree the s-expression tries to
> communicate.
>
> This family tree
>
> (grand-father
> (father
> (me)
> (my-brother))
> (my-uncle
> (my-cousin)))
>
> is actually, when inspected more closely, like this (using the ngr
> syntax):
>
> anonymous-list {
> grand-father
> anonymous-list {
> anonymous-list:me
> anonymous-list:my-brother
> }
> anonymous-list {
> anonymous-list:my-cousin
> }
> }
>
> 10 symbols, 6 of which are "anonymous-list", which has no meaning in the
> domain of family trees.
Now just wait a minute.
You take a simple S-expression, translate it into a more verbose
rendering in another language and then complain that the additional
items added by that translation make it verbose and ugly? Why add those
additional, meaningless tokens?
Lisp doesn't have them. Lisp doesn't need them.
Why not just stick with the S-expression syntax, instead of moving to
the (IMHO) broken ngr syntax. What benefit do you get from the
translation? If you find yourself thinking more naturally in ngr,
perhaps you need to spend more time immersing yourself in S-expressions,
so that you don't feel a need to add these uninformative and confusing
additional symbols.
--
Thomas A. Russ, USC/Information Sciences Institute
On Wed, 16 Oct 2007, Thomas A. Russ wrote:
> You take a simple S-expression, translate it into a more verbose
> rendering in another language and then complain that the additional
> items added by that translation make it verbose and ugly? Why add those
> additional, meaningless tokens?
Because they are there. With practice lisp users are able to filter them
out. But you shouldn't filter them out so completely that you are blind to
them even when somebody points at them. Using a syntax that makes it
possible.
> Lisp doesn't have them. Lisp doesn't need them.
> Why not just stick with the S-expression syntax, instead of moving to
> the (IMHO) broken ngr syntax. What benefit do you get from the
> translation? If you find yourself thinking more naturally in ngr,
> perhaps you need to spend more time immersing yourself in S-expressions,
> so that you don't feel a need to add these uninformative and confusing
> additional symbols.
ngr is "broken" if it is used as a replacement for s-expressions. And vice
versa. Both have their uses.
- Ville Oikarinen
From: =?UTF-8?B?QWxla3NhbmRlciBOYWJhZ8WCbw==?=
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <ff2buq$gh5$1@srv.cyf-kr.edu.pl>
!
Ville Oikarinen napisał(a):
> Please don't ignore this post as "just another rant about lisp
> parentheses", but read on. This may not be new, but at least I try to
> recognize both the merits and problems of s-expressions :)
> ...
> What do you think? Could this be the reason why people dislike
> s-expressions, but at the same time are generally quiet about
> m-expressions (used in mathematica) and the groovy builder syntax (mostly
> same as m-expressions but without the commas; the ngr syntax of ngrease is
> based on this)? Even XML seems to get less critique than s-expressions.
s-expressions begin to look excellent
from the point when somebody learns how to
avoid (progn ...) in 99.8% cases.
--
A
.
Hi Ville Oikarinen,
this reminds me of something I have thought about lately. The
difference between s-exp "(a b c)" and "a {b c}" is much more general
than one might think at first.
It is the difference between strong and weak association of objects
and structure.
It reminds me of a collection library i have thought about.
A set can be represented as a set simply containing stuff which does
not know anything about being contained in there. But it could also be
represented by setting a boolean flag for the objects. "I'm in
there.". Graphs are often implemented by choosing to have a "strong"
binding to the structure by giving the nodes pointers to their
neighbors. But it could as well be implemented by a set of relations.
Or general nodes which have a "content" pointer. The objects don't
need to know about their structure.
When you look at it this way it might make more sense to see s-exp as
a way to combine structure and content in a weak way. The content need
not know anything about structure and thus can be found in different
structure in different contextes. This emphasises the "symbol" which
is a word which is connected to different interpretations which are
chosen depending on the context the word is found in. Some of these
connections again are strong (the symbol p-list, the function-value,
etc.) and some are weak like when a macro like loop interpretes the
symbol.
One key point of weak structure is that processing of this structure
can be done in a general way. It is somewhat more complex for strong
structure to archive reuse of code that operates on it.
One could argue because a symbol in lisp in itself has a set of
different meanings and can only be interpreted in context and
structure, and even there meanings unknown of might arise, that this
is a much closer match to how language works than a strong tree.
Indeed lisp is like ascii art :)
From: Damien Kick
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <13hb0qe1jcqa39e@corp.supernews.com>
Ville Oikarinen wrote:
> Hello.
>
> Please don't ignore this post as "just another rant about lisp
> parentheses", but read on. [...]
<sigh> Oh, man. Here goes the (/ signal noise). <breath type="deep">
"Once more unto the breach, dear friends, once more/ Or close the wall
up with our Lispnik dead"
> In may I wrote in c.l.l:
>
> "Then, about the Lisp's "Head insinde parentheses" convention. Like Xah
> Lee demonstrated, [...]"
<sigh type="of relieve"> I almost thought I was going to have to pay
attention to this thread. Xah Lee? Go fly a frog.
On 2007-10-16 23:36:56 -0400, Damien Kick <·····@earthlink.net> said:
> Go fly a frog.
This has got to be the standard c.l.l troll blow-off line from now on -
brilliant!
From: Ken Tilton
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <E%rRi.52$V76.6@newsfe12.lga>
Ville Oikarinen wrote:
> Hello.
>
> Please don't ignore this post as "just another rant about lisp
> parentheses", but read on.
I am not sure if I complied with your wishes. I read on and /then/
ignored this post. Until today I saw you converging on a savages
allegation, so I thought I would help out by pointing out all the
problems with this article, which does have the charm of keeping the I
have this great idea for Lisp! keep an open mind!! metronome from
missing a beat. (Could one of you smart people good with numbers chart
these things, see if we can make money off it somehow?)
> This may not be new, but at least I try to
> recognize both the merits and problems of s-expressions :)
Buddha would have been able to help here. Thou shalt not make
discriminations. s-expressions simply are. they have neither merits nor
problems. Those come from you. [Cue Erik.]
>
> I already touched this question last may in this group, but I'd like to
> hear more what you lispers think of it.
Five months to recover? We may have a gone a little overboard with the
savagery.
>
> So the question is: Could it be that people who feel uncomfortable with
> lisp parentheses just can't express themselves clearly: it's not the
> parentheses per se but the way they are used that bothers them.
Bzzzt. Sorry. No one who tries Lisp feels uncomfortable with parentheses
for more than a cup of coffee. Premise demolished, thread rewinds on
spool, game over. Thanks for playing. Tim, do we have a door prize?
>
> Here is the problem (published yesterday at
> http://ngrease.sourceforge.net/introduction.html#Lispdialects):
>
> "S-expressions are fine, but as a base for domain specific languages they
> have one flaw: they are not a natural match for trees. An s-expression is
> either a childless singular or an anonymous list. A tree is generally
> represented as an anonymous list, whose first element is _interpreted_ as
> the root and the rest are _interpreted_ as the children.
Not by me. I have all the CARs as siblings in my mental model. I have an
implementation of Erik's idea for QUADs if you need it. Forget the
deets, but it was parent-aware.
Me, I use CLOS most of the time cuz of Cells, so I just have a slot for
parents and a slot for kids. Could it be that no one uses Cells because
they are uncomfortable with that? Nah, they just do not use Cells.
kenneth
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
From: Dimiter "malkia" Stanev
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <5no1viFj7asbU1@mid.individual.net>
>> I already touched this question last may in this group, but I'd like to
>> hear more what you lispers think of it.
>
> Five months to recover? We may have a gone a little overboard with the
> savagery.
>
Was that a time-shift cross-posting?
He talks about last May, you talk about 5 months to recover, and it's
October.
From: Ken Tilton
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <nYARi.7664$4Y4.4468@newsfe12.lga>
Dimiter "malkia" Stanev wrote:
>>> I already touched this question last may in this group, but I'd like to
>>> hear more what you lispers think of it.
>>
>>
>> Five months to recover? We may have a gone a little overboard with the
>> savagery.
>>
>
> Was that a time-shift cross-posting?
>
> He talks about last May, you talk about 5 months to recover, and it's
> October.
Nonsense:
(- 10 5) -> 5
I think I have that right...Oh, god. Don't tell me you think a
non-native speaker used "last" correctly?! Well, your non-nativeness
shows, nothing wrong with that, and it is cool you know the usage even
though you then erred by assuming the OP did.
(a) Many Americans screw up next and last, and I must say it is not even
clear that the correct usage is universally accepted, so I cannot even
say all of them are screwing it up, but I think most of them are.
(b) An adept at the language would simply have said "last year".
The Kenny puts his 5-dollar chip on May, 2007.
Of course, if you all meant was that (- 10 5) -> 6, or that I am so
punchy from working on some code of mine that severely needs refactoring
that I have misnumbered the months, I will be terribly embarrassed by
having given that tedious lecture on the interpretation of natural
second languages.
hth,kzo
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
On Oct 17, 6:54 pm, Ken Tilton <···········@optonline.net> wrote:
> Tim, do we have a door prize?
We did, but that frog guy stole them all. Agents have been dispatched
to, ah, recover them.
From: Ken Tilton
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <WrsRi.53$V76.7@newsfe12.lga>
Ville Oikarinen wrote:
> Hello.
>
> Please don't ignore this post as "just another rant about lisp
> parentheses",...
No, I tawt I thaw yet another spamming attempt to dress up selling your
ngrease project as a deep philosophical reevaluation of Lisp
... but read on. This may not be new, but at least I try to
> recognize both the merits and problems of s-expressions :)
http://www.barbneal.com/wav/ltunes/sylvester/sylv15.wav
>
> I already touched this question last may in this group, but I'd like to
> hear more what you lispers think of it.
http://www.barbneal.com/wav/ltunes/sylvester/sylv12.wav
>
> So the question is: Could it be that people who feel uncomfortable with
> lisp parentheses just can't express themselves clearly: it's not the
> parentheses per se but the way they are used that bothers them.
http://www.barbneal.com/wav/ltunes/sylvester/sylv02.wav
No one who tries Lisp ever has a problem with s-exprs, bye bye premise,
bye bye ngrease, take froggy with you on the way out, would you old man?
>
> Here is the problem (published yesterday at
> http://ngrease.sourceforge.net/introduction.html#Lispdialects):
http://www.barbneal.com/wav/ltunes/sylvester/Sylv45.wav
>
> "S-expressions are fine, but as a base for domain specific languages they
> have one flaw: they are not a natural match for trees.
Would you like my implementation of Erik's quad alternative?
> All these other syntaxes are quite suitable for expressing trees. Is this
> the reason they are more "acceptable" for the masses?
Actually the masses would love Lisp but c.l.l is kinda the Great Wall of
Lisp keeping them out. A new flying variant emerged this spring, we
still have not figured out how to stamp out that pest.
http://www.barbneal.com/wav/ltunes/sylvester/Sylv39.wav
kt
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
On Wed, 17 Oct 2007, Ken Tilton wrote:
> No, I tawt I thaw yet another spamming attempt to dress up selling your
> ngrease project as a deep philosophical reevaluation of Lisp
I don't need to sell it. Especially not to lispers. It's just a tool for
myself. If somebody else finds it usable, fine.
ngrease is not intended as a replacement for lisp. And never will be (I
guess :-). In fact, I might well use scheme for other things in the
future. (And in this context scheme is a lisp.)
The reason why I post here is that I'm genuinely interested in languages
and I believe there is lots of insight to be learned from lispers and in
c.l.l, I just need to endure a lot of arrogant and childish hostility. But
still I believe it's worth it.
- Ville Oikarinen
From: Ken Tilton
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <fXFRi.3808$V76.77@newsfe12.lga>
Ville Oikarinen wrote:
>
> On Wed, 17 Oct 2007, Ken Tilton wrote:
>
>
>>No, I tawt I thaw yet another spamming attempt to dress up selling your
>>ngrease project as a deep philosophical reevaluation of Lisp
>
>
> I don't need to sell it. Especially not to lispers. It's just a tool for
> myself. If somebody else finds it usable, fine.
>
> ngrease is not intended as a replacement for lisp. And never will be (I
> guess :-). In fact, I might well use scheme for other things in the
> future. (And in this context scheme is a lisp.)
>
> The reason why I post here is that I'm genuinely interested in languages
> and I believe there is lots of insight to be learned from lispers and in
> c.l.l, I just need to endure a lot of arrogant and childish hostility. But
> still I believe it's worth it.
Careful climbing down off that high horse. In the midst of the fun I
pointed out that the entire premise of your thread was, um,
counterhistory. Since it went ignored, I repeat: no one ever has a
problem with Lisp, lists, or trees. The only noise we hear is from
people justifying why they are sticking to some retarded other language,
and dat dont count. So....why the thread? I mean, others are looking for
a distraction from froggy and so have joined in, but none of them agree
with your premise either.
kzo
ps. Ignored also was my offer of an implementation of Erik's quad, a
parent-aware tree thingy built of nothing but conses (tho he feels that
in the end a quad may as well be a defstruct). Pity. k
--
http://www.theoryyalgebra.com/
"Career highlights? I had two. I got an intentional walk
from Sandy Koufax and I got out of a rundown against the Mets."."
- Bob Uecker
Ken Tilton wrote:
> ... but read on. This may not be new, but at least I try to
>> recognize both the merits and problems of s-expressions :)
>
> http://www.barbneal.com/wav/ltunes/sylvester/sylv15.wav
>
>>
>> I already touched this question last may in this group, but I'd like to
>> hear more what you lispers think of it.
>
> http://www.barbneal.com/wav/ltunes/sylvester/sylv12.wav
Thanks, that's great, the original sounds much better than the German
synchronizing :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Pascal Costanza
Subject: [OT] Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <5nombcFj2ncdU1@mid.individual.net>
Frank Buss wrote:
> Ken Tilton wrote:
>
>> ... but read on. This may not be new, but at least I try to
>>> recognize both the merits and problems of s-expressions :)
>> http://www.barbneal.com/wav/ltunes/sylvester/sylv15.wav
>>
>>> I already touched this question last may in this group, but I'd like to
>>> hear more what you lispers think of it.
>> http://www.barbneal.com/wav/ltunes/sylvester/sylv12.wav
>
> Thanks, that's great, the original sounds much better than the German
> synchronizing :-)
English native speakers won't understand this: The English word for the
German "synchronisieren" is "dubbing."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Mon, 29 Oct 2007 07:47:01 +0000, Jon Harrop <······@jdh30.plus.com>
wrote:
>Ville Oikarinen wrote:
>> This is a very good example of how a language's primary use dictates its
>> design. Lisp, as a general-purpose language, is designed to make it
>> maximally easy to create and execute function calls.
>
>Then why does this simple function application:
>
> f x y
>
>become this in Lisp:
>
> ((f x) y)
It doesn't. More proof that you don't pay attention. Lisp does not
automatically curry functions - a 2 argument function call in Lisp has
2 arguments: f x y is written as (f x y).
((f x) y) is not even legal Lisp (Common or any dialect I know of).
You need fun call to call a function not in the first position of the
s-expr. Even if (f x) did return a function applicable to y, the
syntax to use it as intended would be (fun call (fun call f x) y).
((f x) y) is a legal construct in Scheme, but Scheme does not curry
either so it is not equal to "f x y".
George
--
for email reply remove "/" from address
On Mon, 29 Oct 2007 21:40:25 -0400, George Neuner
<·········@/comcast.net> wrote:
>syntax to use it as intended would be (fun call (fun call f x) y).
Wow! funcall became fun!
George
--
for email reply remove "/" from address
From: Kent M Pitman
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <ulk9kzal4.fsf@nhplace.com>
George Neuner <·········@/comcast.net> writes:
> On Mon, 29 Oct 2007 21:40:25 -0400, George Neuner
> <·········@/comcast.net> wrote:
>
> >syntax to use it as intended would be (fun call (fun call f x) y).
>
> Wow! funcall became fun!
Just now? funcall was always fun to call. It beats competitive
language schemes, which rush to take the so-called fun right out of
it, leaving their users in a func all of the time.
From: Klaus Schilling
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <87sl3urlvb.fsf@web.de>
Jon Harrop <······@jdh30.plus.com> writes:
>
> Then why does this simple function application:
>
> f x y
>
> become this in Lisp:
>
> ((f x) y)
because the latter is more readable than the parenless crap
>
> People do not write a lot of Mathematica m-exprs or XML by hand.
only mindless pervies would avoid writing those by hand.
> If you look
> at programming languages, the overwhelming consensus is that syntax is
> good, infix operators are good and so forth.
>
infix operators are unconditionally dirty and disgusting,
and thus those who prefer infix syntax are sadomasochist perverts.
Only inferior programming languages use a lot of infix stuff.
Klaus Schilling
From: Thomas A. Russ
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <ymik5p442vv.fsf@blackcat.isi.edu>
Jon Harrop <······@jdh30.plus.com> writes:
>
> Then why does this simple function application:
>
> f x y
>
> become this in Lisp:
>
> ((f x) y)
So you can tell that it isn't really
(f (x y))
After all, there isn't any way to know whether the value or function of
X is what is being referred to.
> If you look
> at programming languages, the overwhelming consensus is that syntax is
> good, infix operators are good and so forth.
Well, arguing from that starting point, there would never be any
progress. Before Java, automatic storage management would have been
bad, explicitly visible pointers good, and so forth.
Infix operators have various limitations, requiring either the same
number of parentheses (just in different places) or else requiring
(somewhat arcane?) precedence rules (see that thread). They also tend
to more drastically limit the set of characters that are available as
identifiers, unless you require the infix operators to be separated by
whitespace. Even if you do require the whitespace, it becomes harder to
pick apart:
A = m/s / t
--
Thomas A. Russ, USC/Information Sciences Institute
From: Jon Harrop
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <13ifif1hn763s78@corp.supernews.com>
Thomas A. Russ wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>>
>> Then why does this simple function application:
>>
>> f x y
>>
>> become this in Lisp:
>>
>> ((f x) y)
>
> So you can tell that it isn't really
>
> (f (x y))
Yet the compilers and programmers for many modern FPLs have no problem with
this, or with 1+2*3.
> After all, there isn't any way to know whether the value or function of
> X is what is being referred to.
There is no need for that Lisp-specific baggage either.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
From: Jon Harrop
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <13ifj3qcve1707a@corp.supernews.com>
Kent M Pitman wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> > This is a very good example of how a language's primary use
>> > dictates its design. Lisp, as a general-purpose language, is
>> > designed to make it maximally easy to create and execute function
>> > calls.
>>
>> Then why does this simple function application:
>>
>> f x y
>>
>> become this in Lisp:
>>
>> ((f x) y)
> ...
> Now, back to your highly contrived example...
My example is simply a blindingly-obvious counter-example to the previous
comment. Lisp is poor at handling functions and Common Lisp was a step
backwards in this respect. Scheme is less ridiculous but still imposes a
significant overhead compared to modern languages.
Dreaming up some absurd analogy where the vast majority of drivers choose
cars without steering wheels highlights your belief as an unjustifiable
religious stance and does not constitute a reasonable response.
The only reasonable response a Lisper can give here is to claim that
homogeneous syntax aids the use of macros but, in fact, macros are used to
workaround the immense hindrance of using such a syntactically bare
language. A deceived newbie would at least have to study a little Lisp
before realised that.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u
On 2007-10-30 20:20:20 -0400, plummeting pond-scum said:
> The only reasonable response a Lisper can give here is to claim that
> homogeneous syntax aids the use of macros but, in fact, macros are used to
> workaround the immense hindrance of using such a syntactically bare
> language. A deceived newbie would at least have to study a little Lisp
> before realised that.
You're absolutely right. The Donut Dromedary and the Sonorously
Serrated Sixth Letter Language are far superior. You should use them
exclusively.
Might I suggest comp.lang.functional for any further discussion? And
please take any nubs foolish enough to fall for your rhetoric with you
- you do realize that you are single handedly assembling a group of
functional programmers pre-selected to be dopey enough to fall for a
spammer, right?
Thanks for taking the weak minded off our hands.
Oh, and don't let the door hit you in the ass on the way out...
From: Jon Harrop
Subject: Re: Do people dislike parentheses or the conceptual mismatch with trees?
Date:
Message-ID: <13ifj5o1nf0497b@corp.supernews.com>
Kamen TOMOV wrote:
> If it were so overwhelming they wouldn't use prefix to call a
> function, e.g. f(param1, param2, etc) and so forth.
They don't, e.g. 1+2. Indeed, that was the whole point...
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?u