1) XML for markup uses angle brackets and verbose syntax for tags
because it is intended to be used with plain text and should clearly
stand out (and use unusual for plain text characters so you don't have
to escape every parenthesis).
There is no acceptable substitute for TEXT MARKUP based on
s-expressions.
2) The s-exp example of data markup is inadequate,
((a :href "target") "Some text'), not (a (:href "target") ....
3) Anyone who uses either s-expressions or XML markup for manual input
of DATA does a wrong thing. Except for extremely rare cases, both are
crap; and there are better ways to accomplish that. The usefullness of
either XML or S-exp is in consistent processing; both have advantages
and drawbacks for computers, and both are disaster as a format for data
for humans. With s-exp being just a little bit smaller disaster, but
the difference is neglectible.
The main cause for people to enter their data in XML is that they
already familiar with XML as text markup, and their eyes are trained to
perceive it; HTML writers are more frequent than lisp programmers,
after all.
············@gmail.com wrote:
> 1) XML for markup uses angle brackets and verbose syntax for tags
> because it is intended to be used with plain text and should clearly
> stand out (and use unusual for plain text characters so you don't have
> to escape every parenthesis).
I'm sorry, but this is ludicrous. Escaping parens imposes far less
of a burden than that imposed by XML's grossly and unnecessarily
verbose syntax.
> The usefullness of
> either XML or S-exp is in consistent processing; both have advantages
> and drawbacks for computers, and both are disaster as a format for data
> for humans. With s-exp being just a little bit smaller disaster, but
> the difference is neglectible.
S-exprs are proven as a notation for human input, in the form of
the Lisp language family (by proven I mean alternative syntaxes for Lisp
have been proposed, and they have not been successful competing with
S-exprs in this niche). XML for program representation is just a disaster
however you look at it.
Paul
Paul F. Dietz wrote:
> S-exprs are proven as a notation for human input, in the form of
> the Lisp language family (by proven I mean alternative syntaxes for Lisp
> have been proposed, and they have not been successful competing with
> S-exprs in this niche). XML for program representation is just a disaster
> however you look at it.
I agree. For structured data S-exprs are good, and XML sucks.
For text markup use a custom language, with angle brackets instead
of ()s, so you can use ()s in your text:
<p paragraph text, some parts of it <em emphasized>.>
This is easy to write AND easy to parse (probably easier than XML).
==> XML is useless, obsolete crap. It wastes computing resources
and insults the human brain. ;)
Stefan Ram wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>
>>For text markup use a custom language, with angle brackets instead
>>of ()s, so you can use ()s in your text:
>><p paragraph text, some parts of it <em emphasized>.>
>
>
> The details are described here:
>
> http://www.purl.org/stefan_ram/pub/unotal_en
>
Hm, I still prefer my own preprocessed notation for writing html. :)
(don't have docs on the web though)
Stefan Ram wrote:
> Unotal is not intended specifically to write HTML,
> but for any structured information.
> [...]
> My rant on why attributes are not well-implemented in XML is
> following here:
> [...]
Nice, thanks.
What I still wonder is what the distinction between a subelement
and an attribute is. I would make the subelements just into an
attribute I guess:
(container (size "big") (contents (list of elements)))
or just allow attributes to occur more than once, like XML elements:
(rose (owner Jean) (owner Mary))
I don't like to make an arbitrary design distinction between those
two. Still, unotal seems interesting (and of course much more
general than my little hacked-together web-language).
> What I still wonder is what the distinction between a subelement
> and an attribute is.
I'm doubtful that attributes make any sense whatsoever in anything
_except_ a markup language. In markup, the fact that elements and
attributes are in separate namespaces can sometimes be useful. For
example, you can easily distinguish between
<p :lang "en"|I should probably learn English.>
and
<p|I should probably learn <lang|English>.>
In the first case, you are specifying that the paragraph is in
English. In the second case, you are talking about the English
language.
David Mullen wrote:
>>What I still wonder is what the distinction between a subelement
>>and an attribute is.
>
>
> I'm doubtful that attributes make any sense whatsoever in anything
> _except_ a markup language. In markup, the fact that elements and
> attributes are in separate namespaces can sometimes be useful. For
> example, you can easily distinguish between
>
> <p :lang "en"|I should probably learn English.>
>
> and
>
> <p|I should probably learn <lang|English>.>
>
> In the first case, you are specifying that the paragraph is in
> English. In the second case, you are talking about the English
> language.
Er, isn't this the difference between
<p|<Englishlang|I should probably learn English.>>
and
<p|I should probably learn <lang|English>.>
?
--
Randall Randall <·······@randallsquared.com>
"Almost no one takes anything seriously enough to make any
difference. You can't get extraordinary results by assuming
your life and goals aren't worth taking seriously. I run away
when I encounter advice to not take life itself seriously."
-- Samantha Atkins
On 4221 September 1993, David Mullen wrote:
>> What I still wonder is what the distinction between a subelement
>> and an attribute is.
> I'm doubtful that attributes make any sense whatsoever in anything
> _except_ a markup language.
Actually, this distinction is quite common in knowledge representation
systems, although the contrast there is not between attributes and
elements but between attributes and relations. I think, when XML is
used as a modeling tool for data, elements are often used as a poor
man's version of relations.
> In markup, the fact that elements and attributes are in separate
> namespaces can sometimes be useful.
In KR, typically when you don't want to introduce additional objects
(concepts and individuals), because you have no idea how to model
those objects in a sensible way or because you're just to lazy, the
information you want to represent is typically modeled via some "flat"
attribute. When I have some information, about which I know that I'll
never need to be deeply structured, I use an attribute. This carries
over nicely to XML.
I also tend to think of the typical data fields of objects in
object-oriented programming languages as attributes. Only those
attributes which have their own methods (and are hence objects on
their own), I would see as being "related". Come to think of it,
setf-methods probably don't count. :-)
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Ein Computer ist nunmal ein Hochgeschwindigkeitstrottel."
-- Jens Dittmar in de.comp.os.unix.linux.newusers
> I also tend to think of the typical data fields of objects in
> object-oriented programming languages as attributes.
You can implement them that way, but I doubt that _syntactically_
distinguishing between elements and attributes is useful when you
simply want to represent trees of objects. For example, if you have a
"person" object, and a person can have children, you might use this
structure in XML:
<person name="Bob">
<person name="Colin"/>
<person name="Samantha"/>
</person>
But what if we decide that people can have pets, as well? Then you
need subelements of "person":
<person name="Bob">
<children>
<person name="Colin"/>
<person name="Samantha"/>
</children>
<pets>
<chicken name="Henrietta"/>
</pets>
</person>
But now think about the sorts of objects that these elements map to.
In the XML, "children" and "pets" are not attributes; the syntax is
different. But "children" and "pets" _are_ attributes in the sense of
being "data fields" in an object, provided that data fields can be
lists. So the syntactic distinction is starting to look rather
pointless. Let's restore some semblance of sanity:
(person
(name "Bob")
(children
(person (name "Colin"))
(person (name "Samantha")))
(pets
(chicken (name "Henrietta"))))
Here, the syntax is more uniform, but we still know that "name",
"children", and "pets" are all data fields, because we've imposed the
constraint that objects may directly contain _only_ attributes, which,
in turn, may contain _only_ objects. This gives us a way to
distinguish between objects and attributes without mucking up the
syntax.
David Mullen wrote:
> (person
> (name "Bob")
> (children
> (person (name "Colin"))
> (person (name "Samantha")))
> (pets
> (chicken (name "Henrietta"))))
>
> Here, the syntax is more uniform, but we still know that "name",
> "children", and "pets" are all data fields, because we've imposed the
> constraint that objects may directly contain _only_ attributes, which,
> in turn, may contain _only_ objects. This gives us a way to
> distinguish between objects and attributes without mucking up the
> syntax.
That's funny. I saw the XML portion of your post and started
responding. Then I noticed that you already wrote the (almost)
same sexp code with the exact same (not literally) explanation :)
On 4222 September 1993, David Mullen wrote:
>> I also tend to think of the typical data fields of objects in
>> object-oriented programming languages as attributes.
> You can implement them that way, but I doubt that _syntactically_
> distinguishing between elements and attributes is useful when you
> simply want to represent trees of objects.
That may be true, but representing trees of objects is not necessarily
the only purpose of objects (although it's arguably the only purpose
of XML).
> (person
> (name "Bob")
> (children
> (person (name "Colin"))
> (person (name "Samantha")))
> (pets
> (chicken (name "Henrietta"))))
> Here, the syntax is more uniform, but we still know that "name",
> "children", and "pets" are all data fields, because we've imposed the
> constraint that objects may directly contain _only_ attributes, which,
> in turn, may contain _only_ objects.
I can't see anything that imposes that constraint. In particular,
what's contained in your name(-slot) is certainly a string, which is
only an object (in terms of what we're arguing here) when you consider
that in CLOS you may treat it that way. Still, that was not the kind
of objects I was referring to. There is a difference between one's
/property/ of having a "name" and the /relation/ to one's children or
pets and if you want to reflect that difference in your syntax [1], I
fail to see that in your "more uniform" syntax. What your sexp shows
is that it's possible to embed deeply structured information in it,
but that hardly comes as a surprise.
> This gives us a way to distinguish between objects and attributes
> without mucking up the syntax.
I agree that mucking up syntax is not required to achieve that,
although I certainly believe that syntactic beauty is in the eye of
the beholder, too.
Holger
Footnotes:
[1] Most of the time I certainly don't want to, just to make that clear.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
81: Cursor-Tasten
Neumodischer Schnickschnack. (Gert D�ring)
+ ···@zedat.fu-berlin.de (Stefan Ram):
| <meta
| content="noarchive"
| name="robots"
| ></meta>
This is not correct, I think. It should be
<meta
content="noarchive"
name="robots"
/>
should it not? Does your notation allow a distinction between an
empty element and one whose content is the empty string?
(Sorry 'bout the nitpicking. This is usenet after all. Nice rant.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
+ ···@zedat.fu-berlin.de (Stefan Ram):
| Harald Hanche-Olsen <······@math.ntnu.no> writes:
| >| <meta
| >| content="noarchive"
| >| name="robots"
| >| ></meta>
| >This is not correct, I think. It should be
| > <meta
| > content="noarchive"
| > name="robots"
| > />
| >should it not?
|
| I am not aware of anything in XML or XHTML 1.1 requiring this.
Oops, you're right, at least partly.
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-starttags
[...]
The representation of an empty element is either a start-tag
immediately followed by an end-tag, or an empty-element tag.
[...]
Empty-element tags MAY be used for any element which has no content,
whether or not it is declared using the keyword EMPTY.
On the other hand it also says:
For interoperability, the empty-element tag SHOULD be used, and
SHOULD only be used, for elements which are declared EMPTY.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
+ ···@zedat.fu-berlin.de (Stefan Ram):
| >For interoperability, the empty-element tag SHOULD be used, and
| >SHOULD only be used, for elements which are declared EMPTY.
|
| As far as I understand this, it restricts the use of the
| empty-element tag. But since my code does not not use the
| empty-element tag at all, this interoperability requirement
| does not seem to apply to my code.
Well, the "SHOULD only" restricts the empy-element tag, but the first
"SHOULD" recommends its use, e.g., for the meta tag. Of course,
"SHOULD" is not "MUST", so your code is perfectly legal. How strongly
you wish to interpret "SHOULD" is up to you, and (perhaps more to the
point) to the applications that will end up reading XML generated by
your code.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Stefan Ram <···@zedat.fu-berlin.de> wrote:
+---------------
| Ulrich Hobelmann <···········@web.de> writes:
| >For text markup use a custom language, with angle brackets instead
| >of ()s, so you can use ()s in your text:
| ><p paragraph text, some parts of it <em emphasized>.>
|
| The details are described here:
| http://www.purl.org/stefan_ram/pub/unotal_en
+---------------
You might also want to Google for TML (Trivial Markup Language)
or DMTML (but *not* the same "DTML" that's used in Zope!), which
is a another markup format that uses angle brackets. Originally
suggested here in c.l.lisp by Erik Naggum, it was picked up by
Tim Bradshaw & co., and used by them for a number of sizable
documentation projects, IIRC. It's basically angle-bracket sexps,
with the addition of SGML/HTML/MXL attributes as CL keyword/value
pairs, and one or two other optional marker characters to resolve
ambiguities (e.g., end of attributes) and make the common cases
easy to write manually. E.g.:
<tocify
<indexify
<h1|first heading...>
<p|...>
<p|This is some <font :color "red"|bright red> text.>
...
<index :title "Index">>>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
············@gmail.com <············@gmail.com> schrieb:
> Anyone who uses either s-expressions or XML markup for manual input of
> DATA does a wrong thing.
Programs aren't data? Or do you wish we had M-exps?
Adrian Kubala wrote:
> ············@gmail.com <············@gmail.com> schrieb:
> > Anyone who uses either s-expressions or XML markup for manual input
of
> > DATA does a wrong thing.
>
> Programs aren't data? Or do you wish we had M-exps?
It is because of this attitude LISP has such a bad fortune. Progams and
data are the same thing when you treat programs as data, not when you
treat a human as a REPL. Programs are data, but humans are not LISP
programs.
M-expressions are equally irrelevant; humans live well enough without
parentheses or pointy brackets; for humans, much more handy tools are
color marks, out-of-line marks, or just indents (as lisp or wiki
suggests). For certain types of data, tabular interactive forms are
much better for input than s-expressions, or x-expressions, or
m-expressions, or whatever other expressions handy for processing by
machines by hard for human perceptions.
In this respect, s-expressions and XML are equally bad, with XML
slightly better because it allows to solve a wider range of tasks (both
mixed content and data markup), while s-expressions don't work for
mixed content.
············@gmail.com <············@gmail.com> schrieb:
> M-expressions are equally irrelevant; humans live well enough without
> parentheses or pointy brackets; for humans, much more handy tools are
> color marks, out-of-line marks, or just indents (as lisp or wiki
> suggests). For certain types of data, tabular interactive forms are
> much better for input than s-expressions, or x-expressions, or
> m-expressions, or whatever other expressions handy for processing by
> machines by hard for human perceptions.
So far all of your counterexamples are so trivial that it doesn't make a
bit of difference how you represent them. Tables of phone numbers? Text
markup? Who cares about a ( here or a < there? Try comparing some *real*
data: a pageful of Haskell code (arguably the best pseudo-math-syntax
language) with a pageful of Lisp code. Or compare to a handwritten math
proof if you like. They'll all be about equally hard to understand,
because of the beautiful truth that:
- Fancy syntax only operates at a small scale (one or two lines of code
at most), and because of the small scale the benefit is relatively
small. It costs you what, like .0001 seconds longer to grok (setq x 3)
over x := 3?
- Whereas at the large-scale level where almost all your comprehension
is focused, fancy syntax doesn't buy you anything, and regular syntax
buys you abstraction power.
> So far all of your counterexamples are so trivial
That's because I remember what the thread is about. The thread is about
the prevalence of s-exp over lisp for human input and perception, and
about the taste of Tim Bray. And the fact is that both XML and s-exp
are regular syntax, and both are created for programs, not for humans;
and for a human, both are unnatural (artificial?).
Whether it is good or bad to distinguish between elements and
attributes is not a point just because Common Lisp draws the
distinction pretty clearly through the use of keywords in structure
declarations, for example; countable and orderable (elements) has a
different syntax from non-countable and non-orderable (attributes) in
Common Lisp in pretty much the same way as it does in XML.
Both s-expressions and XML are good for computers and bad for humans,
unless humans are specially trained; and when they are trained, they
both are good because if XML read without a computer aid, named end
tags help in the case of mixed content, and when it is read with an
aid, such as Emacs, tags can be hidden, folded and decorated in any
way. s-exp is a more concise notation, which means in the case of data
somewhat, but hopelessly looses for mixed content.
SGML, the XML's predecessor had means to configure itself via DTD to
look like anything, including l S-expressions (that is, parentheses and
no name in the end tag). However, another syntax had won for XML, just
because it is uniform, powerful and allows uniform processing for a
much wide range of tasks.
In general, a custom solution is always better when a uniform one, just
because it is best-tuned for one particular task; but having a single
approach which works well enough for a range of tasks instead of having
a separate of approach which would work best for each of the tasks in
the range is usually an advantage -- just because you are free from
thinking about the approach and bugs in it.
············@gmail.com wrote:
>>So far all of your counterexamples are so trivial
>
>
> That's because I remember what the thread is about. The thread is about
> the prevalence of s-exp over lisp for human input and perception, and
> about the taste of Tim Bray. And the fact is that both XML and s-exp
> are regular syntax, and both are created for programs, not for humans;
> and for a human, both are unnatural (artificial?).
Then how come Lisp coders write their program code in sexps?
Certainly, you say, it would be better to have some frontend to
output it as XML. We are human, but still we directly interact
with those sexps. We don't use Haskell syntax, nor do we use some
graphical representation for some XML.
I know you said (why?) that this bad-for-humans thing only applies
to data. But programs ARE data.
> I know you said (why?) that this bad-for-humans thing only applies
> to data. But programs ARE data.
Programs are data for programs, not for humans. The slogan 'PROGRAMS
ARE DATA' is used as an excuse by poor lisp programmers for not making
human-eligible interfaces instead of s-expressions-based ones for their
programs. Programs are data does not mean program users must program
instead of interacting with programs in humane ways.
············@gmail.com wrote:
>>I know you said (why?) that this bad-for-humans thing only applies
>>to data. But programs ARE data.
>
>
> Programs are data for programs, not for humans. The slogan 'PROGRAMS
> ARE DATA' is used as an excuse by poor lisp programmers for not making
> human-eligible interfaces instead of s-expressions-based ones for their
> programs. Programs are data does not mean program users must program
> instead of interacting with programs in humane ways.
>
What I meant was: any lisp program is an sexp, written by the
human for the compiler to execute.
You wouldn't write programs in XML for a compiler, would you?
> What I meant was: any lisp program is an sexp, written by the
> human for the compiler to execute.
>
> You wouldn't write programs in XML for a compiler, would you?
I do that occasionally; mostly because programs are data, and XSLT
transformations can be transformed and generated using XSLT
transformations; there are examples of big and pretty useful programs
written entirely in XSLT and used by lisp community due to lack of a
tool with comparable features written in Lisp or any other language.
One example is XSLT stylesheets for DocBook XML,
http://docbook.sourceforge.net/projects/xsl . The stylesheets are used
to generate documentation in PDF and HTML for the CVS version of CLISP.
············@gmail.com wrote:
> The slogan 'PROGRAMS
> ARE DATA' is used as an excuse by poor lisp programmers for not making
> human-eligible interfaces instead of s-expressions-based ones for
> their programs. Programs are data does not mean program users must
> program instead of interacting with programs in humane ways.
I PREFER sexp syntax to monstrosities like C++ or Haskell (I also like
Forth and APL, so it's regularity of syntax I like, not prefix vs.
postfix vs. infix). It makes it easier for ME to parse, whatever about
the computer.
I'm human (at least as far as I know. Maybe my parents weren't telling
me something..). I suspect you're projecting your personal preferences
as general rules.
David Golden wrote:
> ············@gmail.com wrote:
>
> > The slogan 'PROGRAMS
> > ARE DATA' is used as an excuse by poor lisp programmers for not
making
> > human-eligible interfaces instead of s-expressions-based ones for
> > their programs. Programs are data does not mean program users must
> > program instead of interacting with programs in humane ways.
>
> I PREFER sexp syntax to monstrosities like C++ or Haskell (I also
like
> Forth and APL, so it's regularity of syntax I like, not prefix vs.
> postfix vs. infix). It makes it easier for ME to parse, whatever
about
> the computer.
This was not about programming languages, but about markup and data
input.
I don't propose that you interact with programs using Haskell or C++.
s-expressions are good
when programs and data need the same representation and it is one of
strenghs of lisp, but
bad for interfaces. Marking up structured text using s-expressions is a
bad idea.
>
> I suspect you're projecting your personal preferences
> as general rules.
I write programs in lisp (along with many other programming languages)
since 1989. I wrote a few programs of considerable size in various
dialects of lisp.
············@gmail.com wrote:
> Marking up structured text using s-expressions is a
> bad idea.
Only because you have surround strings with "", IMHO. I would
*still* prefer it to XML (or XHTML) for text; after doing that for
a week I wrote a custom language that looks like sexps with <>
brackets, and text is implicit. So much shorter.
> s-expressions are good
> when programs and data need the same representation and it is one of
> strenghs of lisp, but
> bad for interfaces.
I realised that was not made clear from my post (the C++/Haskell stuff
was illustrating a general preference for sexp syntax over more
complicated things) and immediately appended an example of an
_application_ I like the ability to interact with sexps with in a
followup post.
Another example would be a lisp web application: the UI
appropriate for the clients connecting might be HTML, the preferred UI
for the sysadmin (many applications give insufficient consideration to
UIs for sysadmins) might be a REPL or CLI that can be telnetted (or,
hopefully in this day and age, SSHed) to. Compared to the complex and
inconsistent CLI UI of some network switches i've used, sexps or
maybe even forth would be great...
> Marking up structured text using s-expressions is
> a bad idea.
>
I regard marking up structured text with sexps OR xml as a bad idea.
Both are restricted to being tree-representation languages, not what I
consider real markup languages.
>> Programs are data does not mean program users
>> must program instead of interacting with programs in humane ways.
>
> I'm human (at least as far as I know. Maybe my parents weren't
> telling
> me something..). I suspect you're projecting your personal
> preferences as general rules.
Ooh, an example from lisp world: The McCLIM Listener is a nice
application, and you can type sexps including sexps that do things to
the listener itself into it. (Aside: it needs have completion
facilities for them, though)
David Golden wrote:
> >> Programs are data does not mean program users
> >> must program instead of interacting with programs in humane ways.
> >
> > I'm human (at least as far as I know. Maybe my parents weren't
> > telling
> > me something..). I suspect you're projecting your personal
> > preferences as general rules.
>
> Ooh, an example from lisp world: The McCLIM Listener is a nice
> application, and you can type sexps including sexps that do things to
> the listener itself into it. (Aside: it needs have completion
> facilities for them, though)
Would Eliza be as attractive if you had to use s-expressions reflecting
the structure of english sentences to talk to it?
············@gmail.com wrote:
> Would Eliza be as attractive if you had to use s-expressions
> reflecting the structure of english sentences to talk to it?
No, that would be stupid. But eliza isn't a UI to my RAID array
controller firmware, say. Given the choice of using some programmer's
misbegotten idea of a "friendly" CLI or GUI interface to _some_
applications, and writing in sexps, I'd often rather (documented) sexps
(maybe with tab-completion).
I don't buy the argument that sexps are unsuitable for all UIs,
many of the UIs I encounter in my daily life would be improved by sexp
support. The distinction between "programming language" and
"application UI" is not sharp. Hence scripting languages (duh), the
console in quake etc. And in such things, I rather simple syntax.
Now, you may say "they're all auxilliary UIs" - but I personally
wouldn't see anything wrong with a pure sexp interface for some
applications.
·············@gmail.com" <············@gmail.com> writes:
> > I know you said (why?) that this bad-for-humans thing only applies
> > to data. But programs ARE data.
>
> Programs are data for programs, not for humans. The slogan 'PROGRAMS
> ARE DATA' is used as an excuse by poor lisp programmers for not making
> human-eligible interfaces instead of s-expressions-based ones for their
> programs. Programs are data does not mean program users must program
> instead of interacting with programs in humane ways.
Please, write the derivative of this function:
(lambda (x) (+ (* 3 x x) (* 5 x) 4))
Please, write the derivative of the function f.
(defun f (x) (+ (* 3 x x) (* 5 x) 4))
Please, prove that this algorithm terminates for all positive x and y:
(defun gcd (x y) (cond ((= x y) x)
((< x y) (gcd x (- y x)))
(t (gcd y (- x y)))))
Note: you're conscious this later question cannot be answered by any
program, aren't you?
Do you still think programs are not data for human?
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot. don't bother saving your artefacts.
>
> Please, prove that this algorithm terminates for all positive x and
y:
>
> (defun gcd (x y) (cond ((= x y) x)
> ((< x y) (gcd x (- y x)))
> (t (gcd y (- x y)))))
>
> Note: you're conscious this later question cannot be answered by any
> program, aren't you?
Yes, I went to college twenty years ago.
>> Do you still think programs are not data for human?
Phrase 'programs are data' means one simple particular thing. That the
program code and data,when represented using the same syntax and
underlying data structures, can be treated in the same way, thus
programs can be processed in the same way as data.
This phrase has nothing to do with the ability of the human being to
read the lisp source code.
············@gmail.com wrote:
> Phrase 'programs are data' means one simple particular thing. That the
> program code and data,when represented using the same syntax and
> underlying data structures, can be treated in the same way, thus
> programs can be processed in the same way as data.
>
> This phrase has nothing to do with the ability of the human being to
> read the lisp source code.
>
Maybe not. But when I write an (if ...), I know that there are
three subelements in it (or two if I want). Just because I as a
human can read it, doesn't mean it isn't structured data.
Pascal Bourguignon <····@mouse-potato.com> schrieb:
> Please, prove that this algorithm terminates for all positive x and y:
>
> (defun gcd (x y) (cond ((= x y) x)
> ((< x y) (gcd x (- y x)))
> (t (gcd y (- x y)))))
>
> Note: you're conscious this later question cannot be answered by any
> program, aren't you?
I'm going to be a smartass: (format t "Yes, the gcd algorithm terminates")
The Church Turing thesis just says there's no program that will answer
correctly for *all* input programs.
+ Adrian Kubala <···········@sixfingeredman.net>:
| Pascal Bourguignon <····@mouse-potato.com> schrieb:
| > Please, prove that this algorithm terminates for all positive x and y:
| >
| > (defun gcd (x y) (cond ((= x y) x)
| > ((< x y) (gcd x (- y x)))
| > (t (gcd y (- x y)))))
| >
| > Note: you're conscious this later question cannot be answered by any
| > program, aren't you?
|
| I'm going to be a smartass: (format t "Yes, the gcd algorithm terminates")
I can be a smartass too. That is not a proof, that is just a (true)
statement. But of course, one could replace the statement by an
actual proof, so your point remains valid.
| The Church Turing thesis just says there's no program that will
| answer correctly for *all* input programs.
Aren't you really thinking about the unsolvability of the general
halting problem? That's a theorem, not a thesis.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> schrieb:
>| The Church Turing thesis just says there's no program that will
>| answer correctly for *all* input programs.
>
> Aren't you really thinking about the unsolvability of the general
> halting problem? That's a theorem, not a thesis.
Well, yeah, I phrased that badly. The Church-Turing Thesis is that
computation is what Turing machines do, which, by way of a theorem,
means that the halting problem is uncomputable. You could take this as
definition, or you might think that if hypercomputation exists then
"computable" will have to take on a broader meaning.
(http://en.wikipedia.org/wiki/Hypercomputer)
Pascal Bourguignon <····@mouse-potato.com> schrieb:
> Please, prove that this algorithm terminates for all positive x and y:
>
> (defun gcd (x y) (cond ((= x y) x)
> ((< x y) (gcd x (- y x)))
> (t (gcd y (- x y)))))
>
> Note: you're conscious this later question cannot be answered by any
> program, aren't you?
The halting theorem says there is no Turing machine that can decide
whether an arbitrary Turing machine will terminate. Two problems with
the above...
1. Any real deterministic computer, having finite memory, is not a
Turing machine but a state machine. So the theorem does not apply. It is
trivial to determine if a state machine terminates (simulate it until it
repeats or terminates - it is guaranteed to do one or the other within
2**N operations where N is the size of the memory in bits).
2. The theorem does not say that it is not possible to determine if the
particular Turing machine (program) above terminates. The Euclidian
algorithm above does terminate and this can be proven.
Tim Josling
+ Tim Josling <····························@nospam.com>:
| 1. Any real deterministic computer, having finite memory, is not a
| Turing machine but a state machine. So the theorem does not apply.
But it does: No finite run of a Turing machine needs more than a
finite amount of tape. And a TM with a finite tape is nothing but a
state machine. So to ask whether a TM will halt is the same as asking
wheter it will halt before running out of tape, no matter how big the
tape we give it. The analogy in the world of real computers is: Will
this algorithm complete, no matter how much memory the computer is
endowed with? Of course, you may well argue that we're only
interested in physical computers, there is a limit to how big we can
make them, given the ten-to-the-eighty-some particles in the universe
to build it from, not to mention the amount of time we're willing to
wait for an answer (much less than the age of the universe!), so the
halting theorem really belongs in the realm of philosophy and can
never have practical applications. In order to be truly practically
useful, it would probably have to be rephrased in terms of the
complexity of the halting decision problem for finite state machines,
but something tells me that the answer would probably not be simple
enough to be useful either. In practice, we just shrug and strive to
make sure our algorithms complete in a reasonable amount of time. But
the halting theorem still provides useful insight, even if seems
useless in any concrete instance.
| 2. [...] The Euclidian algorithm above does terminate and this can
| be proven.
Definitely so. Positive results are easy; it's the negative results
that are hard to prove, and maybe even harder to use.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen wrote:
> + Tim Josling <····························@nospam.com>:
>
> | 1. Any real deterministic computer, having finite memory, is not a
> | Turing machine but a state machine. So the theorem does not apply.
>
> But it does: No finite run of a Turing machine needs more than a
> finite amount of tape. ...
This argument has been made many times before. It relies on the
distinction between infinity at a given moment and unlimited (larger
than any given number eventually and/or depending on the input).
Personally I don't find this persuasive.
The point is that no-one has a Turing machine and any real computer is a
state machine not a Turing machine (but see below) so theorems about
Turing machines do not apply to real computers.
For example the real reason you cannot determine if a student's
programming assignment is looping or will terminate is because it is too
compute intensive to simulate a state machine. This has nothing to do
with Turing machines. In practice though, many students' looping
programs repeat the same state frequently and could possibly be detected.
I haven't seen any results on the computational complexity of
determining if a state machine will terminate. It would be at most O(2**N).
---
There is a literature on hypercomputation which talks about more
powerful machines than Turing machines. They can it seems determine
whether an arbitrary Turing machine + input will terminate. The argument
is made that these machines are not realistic because of the various
infinite things they need. In a sense they are more infinite than Turing
machines because they need actual infiniteness while Turing machines
only need unlimited which is somehow less than infinite at a given
moment but Turing machines are just as impossible to build.
The infiniteness can be the ability to handle real numbers (not floating
point, real real numbers). There was a disputed claim that you might be
able to build one using quantum principles.
http://www.amirrorclear.net/academic/hypercomputation.html
Tim Josling
Tim Josling <····························@nospam.com> writes:
> Pascal Bourguignon <····@mouse-potato.com> schrieb:
> > Please, prove that this algorithm terminates for all positive x and y:
> >
> > (defun gcd (x y) (cond ((= x y) x)
> > ((< x y) (gcd x (- y x)))
> > (t (gcd y (- x y)))))
> >
> > Note: you're conscious this later question cannot be answered by any
> > program, aren't you?
>
>
> The halting theorem says there is no Turing machine that can decide
> whether an arbitrary Turing machine will terminate. Two problems with
> the above...
>
> 1. Any real deterministic computer, having finite memory, is not a
> Turing machine but a state machine. So the theorem does not apply. It
> is trivial to determine if a state machine terminates (simulate it
> until it repeats or terminates - it is guaranteed to do one or the
> other within 2**N operations where N is the size of the memory in
> bits).
>
> 2. The theorem does not say that it is not possible to determine if
> the particular Turing machine (program) above terminates. The
> Euclidian algorithm above does terminate and this can be proven.
>
> Tim Josling
Sorry, I just did not want to post an infinite number of algorithms
asking proofs for all of them, just as a rhetorical part of my
question.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Kitty like plastic.
Confuses for litter box.
Don't leave tarp around.
Pascal Bourguignon wrote:
> Please, prove that this algorithm terminates for all positive x and y:
>
> (defun gcd (x y) (cond ((= x y) x)
> ((< x y) (gcd x (- y x)))
> (t (gcd y (- x y)))))
>
Suppose to the contrary that the process doesn't terminate
for two positive integers x and y. Euclid, Book X,
Proposition 2 reads:
If, when the less of two unequal magnitudes is continually
subtracted in turn from the greater, that which is left never
measures the one before it, the magnitudes will be
incommensurable.
thus x and y must be incommensurable. This contradicts the
fact that the unit 1 measures both x and y.
(Note: Proposition 3 shows how to find the greatest common
measure of two given commensurable magnitudes. Proposition 4
shows how to find the greatest common measure of three
commensurable magnitudes - and then comes a porism stating
that the can be extended from three magnitudes to several
magnitudes.)
--
Jens Axel Søgaard
·············@gmail.com" <············@gmail.com> writes:
> Both s-expressions and XML are good for computers and bad for humans,
> unless humans are specially trained;
Perhaps the bit you're missing is that when the humans are
trained, s-expressions are good but XML is _still_ bad.
Alain Picard wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Both s-expressions and XML are good for computers and bad for
humans,
> > unless humans are specially trained;
>
> Perhaps the bit you're missing is that when the humans are
> trained, s-expressions are good but XML is _still_ bad.
This is wrong. I am dealing with people who read and write both mixed
content (text markup) and data in XML. When they are trained, they do
it pretty well. These are the very same peopple who made DSSSL fail
because it was Scheme, and because reading and writing it requires
unusual mindset, which is what James Clark (the inventor of much of
DSSSL, which is s-exp, as well as of XSLT, which is pointy brackets)
has but most people don't. Myself, I am very comfortable with reading
either syntax, and I prefer s-exps for programs and XML markup for
documents when I have to go to the low level of details. In most other
cases, I just use almost plain text techniques and a good translator to
an XML grammar.
David Tolpin
http://davidashen.net/
·············@gmail.com" <············@gmail.com> writes:
> 3) Anyone who uses either s-expressions or XML markup for manual input
> of DATA does a wrong thing. Except for extremely rare cases, both are
> crap; and there are better ways to accomplish that. The usefullness of
Which ways?
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > 3) Anyone who uses either s-expressions or XML markup for manual
input
> > of DATA does a wrong thing. Except for extremely rare cases, both
are
> > crap; and there are better ways to accomplish that. The usefullness
of
>
> Which ways?
Do you have (or had) a phone book? Do|did you use s-expressions to
write down phone numbers of your friends and colleagues? If you do or
did, do you know anybody besides you who does that?
s-expressions are nice for a limited range of tasks because of simple
and uniform processing model. XML, at a cost of slightly more
complicated syntax, provide much more powerful (tree adressing via
XPath, for example) uniform processing for a much wider range of tasks.
None of these tools eases the input or human perception of data, and
they are not for this purpose.
In the world of awful XML technologies, non-xml syntax is often used
for authoring (e.g. the compact syntax for Relax NG); data is best
perceived in tabular representations with indents by spaces and color
marks.
I know this all is about bike shed, of course.
David
············@gmail.com wrote:
> Do you have (or had) a phone book? Do|did you use s-expressions to
> write down phone numbers of your friends and colleagues? If you do or
> did, do you know anybody besides you who does that?
Every number is a valid s-expression. It doesn't even have to be
parsed (later; from a string; like in XML); it's known to be a number.
OTOH, I never wrote down a phone number like this:
<phone name="My Friend">1234567</number>.
(phone "My friend" 1234567) is easier, though most people just
scribble My friend 1234567 on a piece of paper.
> s-expressions are nice for a limited range of tasks because of simple
> and uniform processing model. XML, at a cost of slightly more
> complicated syntax, provide much more powerful (tree adressing via
> XPath, for example) uniform processing for a much wider range of tasks.
> None of these tools eases the input or human perception of data, and
> they are not for this purpose.
What tells you that something like XPath can't be done for an sexp?
What's more uniform processing? Treating attributes and elements
differently?
And if both formats both work for data storage and readability
doesn't matter, then why use the format which takes up almost
twice the storage space (or network bandwidth, or parser bandwidth)?
> OTOH, I never wrote down a phone number like this:
> <phone name="My Friend">1234567</number>.
> (phone "My friend" 1234567) is easier, though most people just
> scribble My friend 1234567 on a piece of paper.
>
That's because both s-expressions and XML are crap for human input and
output.
> What tells you that something like XPath can't be done for an sexp?
>
Because addressing in tree structures is beyond the data model of s
expressions.
> What's more uniform processing? Treating attributes and elements
> differently?
Uniform processing of mixed content markup (text markup) and data
markup.
>
> And if both formats both work for data storage and readability
> doesn't matter, then why use the format which takes up almost
> twice the storage space (or network bandwidth, or parser bandwidth)?
Because network bandwidth and parser bandwidth do not matter, the
difference is neglectible compared to the gains.
············@gmail.com wrote:
>>OTOH, I never wrote down a phone number like this:
>><phone name="My Friend">1234567</number>.
>>(phone "My friend" 1234567) is easier, though most people just
>>scribble My friend 1234567 on a piece of paper.
>>
>
>
> That's because both s-expressions and XML are crap for human input and
> output.
You are in a newsgroup where people write sexps by hand daily!
>>What tells you that something like XPath can't be done for an sexp?
>>
>
>
> Because addressing in tree structures is beyond the data model of s
> expressions.
SExps ARE tree structures. I think you could implement something
like XPath for it (like ML-style pattern matching).
>>And if both formats both work for data storage and readability
>>doesn't matter, then why use the format which takes up almost
>>twice the storage space (or network bandwidth, or parser bandwidth)?
>
>
> Because network bandwidth and parser bandwidth do not matter, the
> difference is neglectible compared to the gains.
The gains are...?
> You are in a newsgroup where people write sexps by hand daily!
Not to enter data. And a LISP program that requires a user to write
s-expressions to communicate to it is a bad one. Imagine Eliza, or
Emacs's doctor asking you to talk to you by means of s-expressions.
> > Because addressing in tree structures is beyond the data model of s
> > expressions.
>
> SExps ARE tree structures. I think you could implement something
> like XPath for it (like ML-style pattern matching).
>
I even did. But it is not a part of the formalism, while in XML it is.
S-expressions are two abstract to have an efficient addressing
mechanism on them, and if you restrict them so that it works, you'll
get XML Infoset (which is unrelated to XML syntax semantically, but
comes in the same package).
> >>And if both formats both work for data storage and readability
> >>doesn't matter, then why use the format which takes up almost
> >>twice the storage space (or network bandwidth, or parser
bandwidth)?
> >
> >
> > Because network bandwidth and parser bandwidth do not matter, the
> > difference is neglectible compared to the gains.
>
> The gains are...?
See above: uniform processing for mixed content (text) and tree
structures (data) markup.
Ulrich Hobelmann wrote:
> SExps ARE tree structures. I think you could implement something like
> XPath for it (like ML-style pattern matching).
Yes, but not with Lisp's default treatment of SExps by parsing them into
cons lists - you don't have a parent or following-sibling axis.
And you can implement such structures in pretty well any programming
language, with pretty well any tree-based input syntax. Saying XML is
equivalent to SExp as it's tree based is as useful as saying C is
equivalent to Lisp as they're both Turing complete.
XML's an interchange standard, and as such has to be politically
neutral; saying you can use Lisp syntax to do the same job makes as much
sense as insisting the text be encoded in EBCDIC. It's also why the
Python and Perl inspired alternatives won't get traction either.
Pete
Pete Kirkham wrote:
> Ulrich Hobelmann wrote:
>
>> SExps ARE tree structures. I think you could implement something like
>> XPath for it (like ML-style pattern matching).
>
>
> Yes, but not with Lisp's default treatment of SExps by parsing them into
> cons lists - you don't have a parent or following-sibling axis.
Why not? If your path is "foo/bar" then your sexps must look like
(foo ... blub ...) where blub looks like (bar ...).
You're always dealing with a list of tagged lists. What's the
problem finding out out if their car matches something?
> And you can implement such structures in pretty well any programming
> language, with pretty well any tree-based input syntax. Saying XML is
> equivalent to SExp as it's tree based is as useful as saying C is
> equivalent to Lisp as they're both Turing complete.
They are. You can easily build an isomorphic transformation btw.
XML and a subset of sexps (that are structured nicely, and include
XMl attributes in a certain way).
> XML's an interchange standard, and as such has to be politically
> neutral; saying you can use Lisp syntax to do the same job makes as much
> sense as insisting the text be encoded in EBCDIC. It's also why the
> Python and Perl inspired alternatives won't get traction either.
AFAI see it, XML is specified and dominated/controlled by the W3C
and a number of companies who build tools for it, or who have
other stakes in it.
For any programmer the learning curve and installation/interfacing
curve is much higher for XML, and don't forget, that you don't
work with XML, you work with one of thousands acronymed
technologies built on top of XML's meta-syntax!
I once wrote a Java program to process some RDF stuff, and it was
mostly hours and hours reading through the spec of RDF, the RDF I
wanted to process, and the API specs for accessing all that stuff.
With sexps I could have written the access functions in that
time myself.
> > Yes, but not with Lisp's default treatment of SExps by parsing them
into
> > cons lists - you don't have a parent or following-sibling axis.
>
> Why not?
Because lisp's default treatment of s-expressions as unidirectional
lists does not provide means for easy traversal of ancestor, sibling
axes, as Pete Kirkham said. Of course, Lisp can be used to implement
XPath for s-expressions, as most other language. As well as XPath for
almost any kind of hierarchical notations. s-expressions are just a
lower-level structure, it does not give you uniform solutions for the
problems (such as XPath addressing, serialization with a different
encoding etc.) which XML addresses.
·············@gmail.com" <············@gmail.com> writes:
> > > Yes, but not with Lisp's default treatment of SExps by parsing them
> into
> > > cons lists - you don't have a parent or following-sibling axis.
> >
> > Why not?
>
> Because lisp's default treatment of s-expressions as unidirectional
> lists does not provide means for easy traversal of ancestor, sibling
> axes, as Pete Kirkham said. Of course, Lisp can be used to implement
> XPath for s-expressions, as most other language.
S-expressions are just a notation for arbitrary nested structures;
not merely a representation of linked-lists containing.
> As well as XPath for almost any kind of hierarchical notations.
> s-expressions are just a lower-level structure, it does not give you
> uniform solutions for the problems (such as XPath addressing,
> serialization with a different encoding etc.) which XML addresses.
S-expressions don't give you a "solution" for anything,
and neither does XML. You need to add meaning to the structure.
·············@gmail.com" <············@gmail.com> writes:
>Because lisp's default treatment of s-expressions as
>unidirectional
Once I had an idea for a system called "colisp". I considered
LISP to be a "notation for programs", and colisp was intended
to be a "notation for data". Because "data" were considered
"co-objects" (dual objects) to programs, I called it "colisp".
LISP conses have a CAR and a CDR.
My idea was to extend every object (cons and atom) with a
"RAC" and a "RDC", that would give colisp just this
bidirectionality (missed by David Tolpin as quoted above).
A RAC would be the list of all conses this object is a CAR in
and a RDC would be the list of all conses this object is a CDR
in.
So, when the database is a database of assertions, using the
RAC and RDC of an object, one could find out all assertions
this object is a part of by just traversing its RAC and RDC.
Then, I wanted to stored any kind of information in such a
colisp database.
In 1991, I managed to implement this in C, but the
implementation was somewhat hard to maintain and use.
Only recently, I have started the experimental test operation
of an information system based on the same principle. While
not written in LISP (nor Lisp) it uses the idea of RACs and
RDCs.
For example, there is an object representing the concept
"Lisp":
http://purl.net/stefan_ram/garnoo/XOCONCEPTXSYLISP
This concept appears as an object in two assertions. The list
of these assertions is somewhat like the "RDC" of the original
idea. One can thus find and use these assertions to browse to
related concepts. (For example, on this page, one can see that
the system knows of two programs, which can "read Lisp".
[Actually, they read an S-expression based language.] I only
recently started this system, so there is not much information
contained in yet.)
This information system "garnoo" is based on an idea that
was attained when thinking about how to remove the
unidirectionality of cons-structures.
·············@gmail.com" <············@gmail.com> writes:
> Because lisp's default treatment of s-expressions as unidirectional
> lists does not provide means for easy traversal of ancestor, sibling
> axes, as Pete Kirkham said.
Erik Naggum discussed his "quad" structure to address these needs in a
January 2004 thread entitled "XML->sexpr ideas".�
Footnotes:
� http://groups-beta.google.com/group/comp.lang.lisp/browse_frm/thread/773c39bf4818d097/f7e4a1167a139959
--
Steven E. Harris
Ulrich Hobelmann wrote:
> Pete Kirkham wrote:
>
>> Ulrich Hobelmann wrote:
>>
>>> SExps ARE tree structures. I think you could implement something
>>> like XPath for it (like ML-style pattern matching).
>> Yes, but not with Lisp's default treatment of SExps by parsing them
>> into cons lists - you don't have a parent or following-sibling axis.
>
> Why not? If your path is "foo/bar" then your sexps must look like (foo
> ... blub ...) where blub looks like (bar ...).
The XPath parent axis matches the parent element, ie the element which
encloses the element you have a reference for. "foo/bar" matches on the
child axis - the child elements named 'bar' of the child elements named
'foo'. The XPaths ".." and "ancestor::foo" use the parent axis. Cons
lists do not have a reference to their enclosing cons, so cannot be used
for this.
> You're always dealing with a list of tagged lists. What's the problem
> finding out out if their car matches something?
If you were put a reference to the parent list in the car of a list, it
conflicts with much of the list processing functions, as you have a
circular reference.
It also, as previously stated, is not Lisp's default treatment of SExps.
Not that you can't implement XML in Lisp, but an XPath equivalent
requires something more than the mapping SExp to cons provided by the
Lisp reader.
>I once wrote a Java program to process some RDF stuff, and it was
>mostly hours and hours reading through the spec of RDF, the RDF I
>wanted to process, and the API specs for accessing all that stuff.
>With sexps I could have written the access functions in that time
>myself.
Yes, it's far easier to use the SExp parser to read KIF than create an
RDF/XML parser in Lisp, and easier to use an JavaBean XMLDecoder or a
properties file than parse an RDF/XML file in Java. But neither's any
use if you want to process a newsfeed. (notwithstanding that RDF/XML is
only one of several encodings of RDF, and RDF/XML is well known to be
broken when it comes to using generic XML tools to process it).
XML is a interchange format, and saying it's not as easy to use in a
given language as a language specific format doesn't alter it's design
goals (some of which it achieved). Saying it's more complicated to the
programmer than say, '()' delimited ASCII, is not useful. Using CORBA to
call a method is more complicated than a normal method call for much the
same reasons.
Pete
Pete Kirkham wrote:
> The XPath parent axis matches the parent element, ie the element which
> encloses the element you have a reference for. "foo/bar" matches on the
> child axis - the child elements named 'bar' of the child elements named
> 'foo'. The XPaths ".." and "ancestor::foo" use the parent axis. Cons
> lists do not have a reference to their enclosing cons, so cannot be used
> for this.
Ok, I don't know the specifics behind XPath, maybe it's more
trimmed to imperative than declarative programming / pattern matching.
> XML is a interchange format, and saying it's not as easy to use in a
> given language as a language specific format doesn't alter it's design
SExps are not language-specific. You can have a parseXML function
that returns lisp lists, just like (read) returns lisp lists.
It's nothing more than a library function, for that matter. Ok,
and you can write reader macros...
> goals (some of which it achieved). Saying it's more complicated to the
> programmer than say, '()' delimited ASCII, is not useful. Using CORBA to
> call a method is more complicated than a normal method call for much the
> same reasons.
But CORBA never really caught on. Ok, I think Mozilla and Gnome
use it, but nobody really seems to like it that much.
I definitely prefer sending sexps over the wire (and interpreting
them) to CORBA. Others do the same thing in XML.
> There is no acceptable substitute for TEXT MARKUP based on
> s-expressions.
But the whole point of S-expressions is that you can write them by
hand if that's convenient, or generate them from something else. For
example, if HTML had been formulated in terms of S-expressions, then
browsers could use a dirt-simple (and _fast_) parser, and authors
could generate Web pages from whatever syntax they prefer. So Peter
Seibel has a markup language for his book, Tim Bradshaw has TML, Adam
Warner has LDF/Syntext, etc. There are so many possibilites. Why do
the XML pushers (especially the W3C) behave as if XML is the _only_
possibility for text markup?
> 2) The s-exp example of data markup is inadequate,
>
> ((a :href "target") "Some text'), not (a (:href "target") ....
The question of whether we actually need attributes is still
debatable. Doesn't anyone remember Erik Naggum's ranting against
attributes from way back? At any rate, I'd say the burden of proof is
on those in favor of attributes.
On Wed, 23 Mar 2005 04:19:19 -0800, David Mullen wrote:
> So Peter Seibel has a markup language for his book, Tim Bradshaw has
> TML, Adam Warner has LDF/Syntext, etc. There are so many possibilites.
> Why do the XML pushers (especially the W3C) behave as if XML is the
> _only_ possibility for text markup?
I'm not certain that's really an advantage. Part of the reasons the web
took off so well is that there were standards on the client, and server
(imperfect though they may be). "Roll your own" is great if you're the
only one having to deal with it. Start bringing in others, and there
needs to be some uniformity. No XML isn't the only possability, but just
how many do people really need to get the job done?
BR wrote:
> I'm not certain that's really an advantage. Part of the reasons the web
> took off so well is that there were standards on the client, and server
> (imperfect though they may be). "Roll your own" is great if you're the
> only one having to deal with it. Start bringing in others, and there
> needs to be some uniformity. No XML isn't the only possability, but just
> how many do people really need to get the job done?
Sure. If you want to send data to a client, and he expects XML,
than you output your data tree in that. Fine.
But if you merely need a data storage format, or something to pipe
between your applications, why not use something simpler and more
(parse time and storage space) efficient, like sexps?
"Ulrich Hobelmann" <···········@web.de> wrote in message ····················@individual.net...
>
> Sure. If you want to send data to a client, and he expects XML, than you output your data tree in that. Fine.
>
If your clients are gray with big heads and black eyes.
The whole origin of XML becomes frighteningly clear in
Graham's 'Hackers & Painters'. Just look up ····@home in
the index.
Now I've got to go and check out those disturbing noises
in the cornfield. :)
--
Geoff
> Just look up ····@home in the index.
Using XML would be the best way to render oneself perfectly invisible
to SETI. (That, or slapping disclaimers on biology textbooks.)
+ ······@umr.edu (David Mullen):
| > 2) The s-exp example of data markup is inadequate,
| >
| > ((a :href "target") "Some text'), not (a (:href "target") ....
|
| The question of whether we actually need attributes is still
| debatable. Doesn't anyone remember Erik Naggum's ranting against
| attributes from way back?
Surely, all longtime residents of c.l.l. do.
| At any rate, I'd say the burden of proof is on those in favor of
| attributes.
I am not going to argue for attributes per se, but in a world filled
with XML which has attributes, if you want to have markup that is
trivially converted to XML then attributes seem like a good thing to
have? Though you could always fake them:
<a <attributes <href target>> Some text>
or even (though it makes me shudder somewhat)
<<a <href target>> Some text>
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
+---------------
| I am not going to argue for attributes per se, but in a world filled
| with XML which has attributes, if you want to have markup that is
| trivially converted to XML then attributes seem like a good thing to
| have? Though you could always fake them:
| <a <attributes <href target>> Some text>
| or even (though it makes me shudder somewhat)
| <<a <href target>> Some text>
+---------------
Tim Bradshaw's TML does that this way:
<a :href "target" | Some text>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
+ ····@rpw3.org (Rob Warnock):
| Harald Hanche-Olsen <······@math.ntnu.no> wrote:
| +---------------
| | I am not going to argue for attributes per se, but in a world filled
| | with XML which has attributes, if you want to have markup that is
| | trivially converted to XML then attributes seem like a good thing to
| | have? Though you could always fake them:
| | <a <attributes <href target>> Some text>
| | or even (though it makes me shudder somewhat)
| | <<a <href target>> Some text>
| +---------------
|
| Tim Bradshaw's TML does that this way:
|
| <a :href "target" | Some text>
I know -- I use it every day -- but you missed my point, which was
concerned with representing attributes without having a specific
notation for them in the markup language.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + ····@rpw3.org (Rob Warnock):
>
> | Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> | +---------------
> | | I am not going to argue for attributes per se, but in a world filled
> | | with XML which has attributes, if you want to have markup that is
> | | trivially converted to XML then attributes seem like a good thing to
> | | have? Though you could always fake them:
> | | <a <attributes <href target>> Some text>
> | | or even (though it makes me shudder somewhat)
> | | <<a <href target>> Some text>
> | +---------------
> |
> | Tim Bradshaw's TML does that this way:
> |
> | <a :href "target" | Some text>
>
> I know -- I use it every day -- but you missed my point, which was
> concerned with representing attributes without having a specific
> notation for them in the markup language.
>
> --
> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
> - Debating gives most of us much more psychological satisfaction
> than thinking does: but it deprives us of whatever chance there is
> of getting closer to the truth. -- C.P. Snow
I googled around a bit to find out about TML, but haven't really
uncovered much. Are there specifications and/or software available
for using TML?
-Klaus.
+ Klaus Harbo <·····@harbo.net>:
| I googled around a bit to find out about TML, but haven't really
| uncovered much. Are there specifications and/or software available
| for using TML?
Um, no, not publicly available. TML (and DTML) is the work of Tim
Bradshaw; see <http://www.tfeb.org/index.html>. I think the only
mention you will see of it in public is his posts here on
comp.lang.lisp. He was going to release it at some point, and I was
going to help write some documentation to make it worth releasing to
the public. But we lost contact along the way. I guess I should make
a new effort to revive this contact and see what can be done. (I now
see a notice on his home page that might explain why contact was
broken.)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
+---------------
| + ····@rpw3.org (Rob Warnock):
| | Tim Bradshaw's TML does that this way:
| | <a :href "target" | Some text>
|
| I know -- I use it every day -- but you missed my point, which was
| concerned with representing attributes without having a specific
| notation for them in the markup language.
+---------------
Ah, I see. Then I would claim that if you don't have
"a specific notation for them in the markup language"
then they're not really "attributes" per se -- certainly
not in the sense meant by SGML/HTML/XML -- they're just
more markup (or more sub-structure).
Google for some of Erik Naggum's rants from long ago
about why attributes [in the SGML/HTML/XML sense] are
basically a bad idea...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
> I am not going to argue for attributes per se, but in a world filled
> with XML which has attributes, if you want to have markup that is
> trivially converted to XML then attributes seem like a good thing to
> have? Though you could always fake them:
> <a <attributes <href target>> Some text>
> or even (though it makes me shudder somewhat)
> <<a <href target>> Some text>
Jukka Korpela's UTD[1] does it this way:
{Ref(url:target) Some text}
UTD is only a proposal, though; I don't know of any implementations.
[1] http://www.cs.tut.fi/~jkorpela/data/utd.html
> I am not going to argue for attributes per se, but in a world filled
> with XML which has attributes, if you want to have markup that is
> trivially converted to XML
Why is this so important? If you need to send data to clients that
require XML, then the odds are that their format will differ from
yours, not only superficially, but _structurally_ as well. So it
isn't realistic to expect to be able to "trivially" convert your data
to any _actual_ XML format. And what if different clients use
different XML schemas? One might use an attribute where the other
uses a subelement. The point being, communication is impossible
unless both sides can agree on a format in _every_ detail, not simply
"Does your format have a cute syntax for attributes?"
······@umr.edu (David Mullen) writes:
> Why is this so important? If you need to send data to clients that
> require XML, then the odds are that their format will differ from
> yours, not only superficially, but _structurally_ as well. So it
> isn't realistic to expect to be able to "trivially" convert your
> data to any _actual_ XML format. And what if different clients use
> different XML schemas? One might use an attribute where the other
> uses a subelement. The point being, communication is impossible
> unless both sides can agree on a format in _every_ detail, not
> simply "Does your format have a cute syntax for attributes?"
Often it won't matter. But I can imagine situations where you want to
round-trip.
Suppose I wanted to manipulate some OpenOffice document, for example:
I could regard that as two-way communication (and so devise some
mapping between OpenOffice's XML and my sexpr structures).
However, I can imagine that being quite a bit more work than simply
choosing some way to map attributes.
+ ······@umr.edu (David Mullen):
| > I am not going to argue for attributes per se, but in a world filled
| > with XML which has attributes, if you want to have markup that is
| > trivially converted to XML
|
| Why is this so important?
For me, currently, (I cannot speak for anyone else) it is only
important whenever I need to hand edit some XML (or HTML) file.
I appreciate the ability to do some trivial transformation to a syntax
that is more easily edited.
| If you need to send data to clients that require XML, then the odds
| are that their format will differ from yours, not only
| superficially, but _structurally_ as well. [...]
Indeed. I have no quarrel with that point of view. But I like to
have trivial solutions to trivial problems rather than having the
trivial problems made more complex because more complex problems also
need to be solved. Ugh, that statement comes perilously close to some
perl slogan, but so be it. 8-)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow