I am very interested in Internet technologies. I consider that they are
so an important revolution as transition from mainframes to PCs was in
the past.
Some time ago, i was newbie and i promoted XML as fascinating future
for the web (aka comunication).
When you do intensive research and usage of XML you find very
disturbing stuff in the XML design. For instance that contrary to
common sense the first child in
<book>
<title>$$$</title>
<author>----</author>
</book>
is *not* the title element!
Moreover, verbosity is a factor (even 10x the size!). That is at the
one hand hype claims that size reduction from transition from HTML
table layouts to CSS design _is_ important, but after XML format is
2-10 times size of other formats. how can a 60% reduction be so
applauded whereas 1000% reductions ignored?
I know many alternatives to XML. Some focus to some subset, example
improvements over XSLT, or input syntaxes for (X)HTML. But there is not
many approaches focusing to provide us an reliable alternative to XML
as a whole.
I know SXML from the Scheme comunity. It is a very good approach. Any
XML doc can be representated in SEXPR and evaluated with Scheme. Cool!
<section>
<title>Introduction to LISP</title>
<para>In this section, we will see the formal properties of
S-EXPR...</para>
...
</section>
becomes
(section
(title "Introduction to LISP")
(para "In this section, we will see the formal properties of
S-EXPR...")
...
)
in S(cheme)XML [1].
There is not new LISP since many time, and projects as that of Arc
appear to me to be 'dead'.
Contrary to P. Graham i do not think that future of LISP would be just
a new dialect [2]. I think that a more fascinating future would be an
web-based LISP.
I am not saying that LISP was not used online today. I am claiming for
an alternative to the XML web becoming from LISP.
That is, i am not claiming that LISP server can be used for generation
on fly of HTML. But that LISP would be at the server (instead XSLT), at
the browser (instead Javascript, instead DOM), at the home (.lsp .lisp
files instead .xml .html), etc.
Would not be fascinating if the evolution of CL was towards a new
standard, clean and specially oriented to web?
What future do you want for the web?
1) W3C XML. With all known fiascos [3]: FO, XSLT 2, MathML, XHTML 2,
SVG 1.2...
2) Microsoft Avalon/XAML. Ampliation of XML. Does not use W3C
technology but propietary markup, i.e. not CSS, not XHTML, not XSLT,
not SVG...
3) WhatWG. A new very critized HTML version usually known as HTML5.
Include a XHTML version compiting (incompatible) with W3C XHTML 2.
4) A new LISP 'dialect' for the web instead Arc, a kind of ISO
standarization of S(cheme)XML with modifications.
Would a ISO standard for an alternative to XML save all of us?
Would a ISO standard [4] kill social perception of LISP?
[1] http://www-128.ibm.com/developerworks/xml/library/x-syntax.html
[2] I agree that CL can be cleaned and actualized.
[3] No browser implements FO or c-MathML. Adobe has abandoned SVG, next
ECMA Office XML standard does not use SVG. Microsoft support XSLT but
does not embrace XSLT 2. WhatWG promotes Canvas alternative to SVG. No
browser vendor is interested in XHTML 2 and none supports it. Etcetera.
[4] I know DSSSL 'fiasco'. XSLT is much based in DSSSL.
Juan R. wrote:
> I am very interested in Internet technologies. I consider that they are
> so an important revolution as transition from mainframes to PCs was in
> the past.
>
> Some time ago, i was newbie and i promoted XML as fascinating future
> for the web (aka comunication).
>
> When you do intensive research and usage of XML you find very
> disturbing stuff in the XML design. For instance that contrary to
> common sense the first child in
>
> <book>
> <title>$$$</title>
> <author>----</author>
> </book>
>
> is *not* the title element!
>
> Moreover, verbosity is a factor (even 10x the size!). That is at the
> one hand hype claims that size reduction from transition from HTML
> table layouts to CSS design _is_ important, but after XML format is
> 2-10 times size of other formats. how can a 60% reduction be so
> applauded whereas 1000% reductions ignored?
>
> I know many alternatives to XML. Some focus to some subset, example
> improvements over XSLT, or input syntaxes for (X)HTML. But there is not
> many approaches focusing to provide us an reliable alternative to XML
> as a whole.
>
> I know SXML from the Scheme comunity. It is a very good approach. Any
> XML doc can be representated in SEXPR and evaluated with Scheme. Cool!
>
> <section>
> <title>Introduction to LISP</title>
> <para>In this section, we will see the formal properties of
> S-EXPR...</para>
> ...
> </section>
>
> becomes
>
> (section
> (title "Introduction to LISP")
> (para "In this section, we will see the formal properties of
> S-EXPR...")
> ...
> )
>
> in S(cheme)XML [1].
>
> There is not new LISP since many time, and projects as that of Arc
> appear to me to be 'dead'.
>
> Contrary to P. Graham i do not think that future of LISP would be just
> a new dialect [2]. I think that a more fascinating future would be an
> web-based LISP.
>
> I am not saying that LISP was not used online today. I am claiming for
> an alternative to the XML web becoming from LISP.
>
> That is, i am not claiming that LISP server can be used for generation
> on fly of HTML. But that LISP would be at the server (instead XSLT), at
> the browser (instead Javascript, instead DOM), at the home (.lsp .lisp
> files instead .xml .html), etc.
>
> Would not be fascinating if the evolution of CL was towards a new
> standard, clean and specially oriented to web?
>
> What future do you want for the web?
>
> 1) W3C XML. With all known fiascos [3]: FO, XSLT 2, MathML, XHTML 2,
> SVG 1.2...
>
> 2) Microsoft Avalon/XAML. Ampliation of XML. Does not use W3C
> technology but propietary markup, i.e. not CSS, not XHTML, not XSLT,
> not SVG...
>
> 3) WhatWG. A new very critized HTML version usually known as HTML5.
> Include a XHTML version compiting (incompatible) with W3C XHTML 2.
>
> 4) A new LISP 'dialect' for the web instead Arc, a kind of ISO
> standarization of S(cheme)XML with modifications.
>
>
> Would a ISO standard for an alternative to XML save all of us?
>
> Would a ISO standard [4] kill social perception of LISP?
>
> [1] http://www-128.ibm.com/developerworks/xml/library/x-syntax.html
>
> [2] I agree that CL can be cleaned and actualized.
>
> [3] No browser implements FO or c-MathML. Adobe has abandoned SVG, next
> ECMA Office XML standard does not use SVG. Microsoft support XSLT but
> does not embrace XSLT 2. WhatWG promotes Canvas alternative to SVG. No
> browser vendor is interested in XHTML 2 and none supports it. Etcetera.
>
> [4] I know DSSSL 'fiasco'. XSLT is much based in DSSSL.
Interesting Post
I personaly don't like XML I think it looks messy! And to be honest
there must bet better ways of expressing stuff ilke that, I have been
thinking of developing some kind of heirachy using hash tables and clos
objects... then making a secure / or insecure (not decided)
communication protocol to allow whole sets of data to be transferred
accross the internet or JUST UPDATES but being able to maintain trees
of data much like XML without the grief
Juan R. wrote:
>
> That is, i am not claiming that LISP server can be used for generation
> on fly of HTML.
Would read
> That is, i am not claiming that LISP server cannot be used for generation
> on fly of HTML.
On Dec 3, 2:27 pm, "Juan R." <··············@canonicalscience.com>
wrote:
> [snip]
> That is, i am not claiming that LISP server can be used for generation
> on fly of HTML. But that LISP would be at the server (instead XSLT), at
> the browser (instead Javascript, instead DOM), at the home (.lsp .lisp
> files instead .xml .html), etc.
>
> Would not be fascinating if the evolution of CL was towards a new
> standard, clean and specially oriented to web?
Great, I see many people have the same and nice ideas :)
I'm learning (in spare time) lisp from a few weeks I thought the same
things.
And you could say that the dtd declaration at the beginning of an xml
file would be
a declaration for the *library* needed to execute the file.
Thus, a web browser would be a kind of repl implementing a library to
do the work
of html, another for css and another for javascript (content,
presentation and dynamicity)...
every new piece of ideas (rss, ...) would be just a library.
Bye,
Thu
······@gmail.com wrote:
> Great, I see many people have the same and nice ideas :)
> I'm learning (in spare time) lisp from a few weeks I thought the same
> things.
>
> And you could say that the dtd declaration at the beginning of an xml
> file would be
> a declaration for the *library* needed to execute the file.
The dtd are eliminated in Web 2.0 by Schemas, are just another XML
file.
> Thus, a web browser would be a kind of repl implementing a library to
> do the work
> of html, another for css and another for javascript (content,
> presentation and dynamicity)...
> every new piece of ideas (rss, ...) would be just a library.
HTML is not Web 2.0.
A XML web browser substitutes HTML by XHTML (XML), CSS by XSL-FO (XML)
and Javascript by XSLT (XML).
Microsoft will do something similar but with propietary XAML
technology. Difference with W3C is that they will not use XAML for
logic layer (except descriptive visual layer) but NET languages
(somewhat as in current ASP approaches).
The question is why Python community is very very active in this topic
and developing a Python based web (XML is substituted by SLiP docs)
whereas Scheme comunity generates SXML (and SSAX, SXPath...) whereas
there is not similar LISP approach (i know)?
I think that this whole set of ideas may be posed at the wrong level of
abstraction. XML and Javascript should be considered merely as object
code. One doesn't program in object code if one has good compilers from
higher level abstractions. (Sometimes you need to go down to the object
code to debug, but hopefully rarely, and even there one often has (or
builds) tools that keep the horrible object code at arms length.) I
assume that I don't have to give example of this for XML -- it should
be self-evident, but examples for Javascript are also common. For
example,Google programs in a Java-like language that compiles to
Javascript. You can argue about their choice of abstraction, but at
least they're not programming in Javascript. Peter Siebel has defined
the beginnings of this for Lisp in a language called Lispscript which
the BioBike/KnowOS engineers use to program that system's Visual
Programming Language. Lispscript isn't quite Lisp -- in fact, it's more
like Javascript with parens, but (as I presumably don't have to argue
here) the parens give you enormous power to build extensive elegant
abstraction through layers of macros -- ending up, in theory, back at
(or as close as you like to) Lisp. You (in theory) never see the
Javascript unless you have to debug down at that level. (Which is, I'm
told by the KnowOS engineers, still all too common, but it's
progressing.)
Juan R. wrote:
> I am not saying that LISP was not used online today. I am claiming for
> an alternative to the XML web becoming from LISP.
>
> That is, i am not claiming that LISP server can be used for generation
> on fly of HTML. But that LISP would be at the server (instead XSLT), at
> the browser (instead Javascript, instead DOM), at the home (.lsp .lisp
> files instead .xml .html), etc.
>
> Would not be fascinating if the evolution of CL was towards a new
> standard, clean and specially oriented to web?
I totally agree that this would be very powerful and exciting to have
Lisp and s-expressions at each and every stage of a distributed data
representation, hyperlinking and computing platform. However, this is
hard to pull off the ground and requires people to buy into Lisp at all
levels. This is very unlikely to happen, so I guess this can only be
experimented with as a research and/or hobbyist project.
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/
Pascal Costanza wrote:
> I totally agree that this would be very powerful and exciting to have
> Lisp and s-expressions at each and every stage of a distributed data
> representation, hyperlinking and computing platform. However, this is
> hard to pull off the ground and requires people to buy into Lisp at all
> levels. This is very unlikely to happen, so I guess this can only be
> experimented with as a research and/or hobbyist project.
However, at server side you can find Java or Python, JS is very popular
at clients, and people type HTML/XML by hand with all of those matching
tags and find natural the tree structure for data.
It looks as if people take the 'best' of LISP and promotes it and got
success.
After note that (times 2 3) is critized but the XML part is
<apply><times/><cn>2</cn><cn>3</cn></apply>
Why the same people promoting the latter does not promotes the former.
If former failed to gain popularity why latter is promoted to be basis
for web 2.0?
In article <·······················@f1g2000cwa.googlegroups.com>,
"Juan R." <··············@canonicalscience.com> wrote:
...
> I am not saying that LISP was not used online today. I am claiming for
> an alternative to the XML web becoming from LISP.
Why would you want to rebuild the web protocols in Lisp?
That would be a huge waste of time with little
benefit.
In my sleepless nights I have this dream of a wide-area network
of scalable Lisp Machines, running presentation based
UIs with a distributed object-oriented CLOS database
at the core. I know that I'm not the only one
who had this dream. Ah, and no undetected buffer overflows.
>
> That is, i am not claiming that LISP server can be used for generation
> on fly of HTML. But that LISP would be at the server (instead XSLT), at
> the browser (instead Javascript, instead DOM), at the home (.lsp .lisp
> files instead .xml .html), etc.
>
> Would not be fascinating if the evolution of CL was towards a new
> standard, clean and specially oriented to web?
>
> What future do you want for the web?
>
> 1) W3C XML. With all known fiascos [3]: FO, XSLT 2, MathML, XHTML 2,
> SVG 1.2...
>
> 2) Microsoft Avalon/XAML. Ampliation of XML. Does not use W3C
> technology but propietary markup, i.e. not CSS, not XHTML, not XSLT,
> not SVG...
>
> 3) WhatWG. A new very critized HTML version usually known as HTML5.
> Include a XHTML version compiting (incompatible) with W3C XHTML 2.
>
> 4) A new LISP 'dialect' for the web instead Arc, a kind of ISO
> standarization of S(cheme)XML with modifications.
>
>
> Would a ISO standard for an alternative to XML save all of us?
>
> Would a ISO standard [4] kill social perception of LISP?
>
> [1] http://www-128.ibm.com/developerworks/xml/library/x-syntax.html
>
> [2] I agree that CL can be cleaned and actualized.
>
> [3] No browser implements FO or c-MathML. Adobe has abandoned SVG, next
> ECMA Office XML standard does not use SVG. Microsoft support XSLT but
> does not embrace XSLT 2. WhatWG promotes Canvas alternative to SVG. No
> browser vendor is interested in XHTML 2 and none supports it. Etcetera.
>
> [4] I know DSSSL 'fiasco'. XSLT is much based in DSSSL.
Well, it is 'demo or die'. Running code is the only valid proof
of ideas.
Rainer Joswig wrote:
> Why would you want to rebuild the web protocols in Lisp?
> That would be a huge waste of time with little
> benefit.
>
I do not think that benefits are small because i do not think of
rebuilding but innovation.
Moreover, 1) 2) and 3) are just doing that for Web 2.0. But via some
new LISP, it could be better. Therein i said Web 3.0.
In the end a lot of money would be saved because Web 2.0 projects
reinvent the way too much. Think of XPath, CSS, XSL-FO, SVG, p-MathML,
Xlink, Xquery, XSLT...
Are you counted how many times the HTML <B> tag has been reinvented in
Web 2.0?
Juan R. <··············@canonicalscience.com> wrote:
+---------------
| Moreover, 1) 2) and 3) are just doing that for Web 2.0.
| But via some new LISP, it could be better. Therein i said Web 3.0.
+---------------
For a cogent analysis of "Web 3.0", see:
http://ars.userfriendly.org/cartoons/?id=20061201
http://ars.userfriendly.org/cartoons/?id=20061202
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Juan R. <··············@canonicalscience.com> wrote:
> +---------------
> | Moreover, 1) 2) and 3) are just doing that for Web 2.0.
> | But via some new LISP, it could be better. Therein i said Web 3.0.
> +---------------
>
> For a cogent analysis of "Web 3.0", see:
>
> http://ars.userfriendly.org/cartoons/?id=20061201
> http://ars.userfriendly.org/cartoons/?id=20061202
>
Great, but this is an informal talk in a newsgroup!
I am not sure that the web cannot be versioned because information can
be.
I do not agree that Web 2.0 is fossilized, only the W3C version appears
to be. Next year, people will begin to interchange lots of
AVALON/XAML/OOML because next Vista will be based in angle brackets.
(message (Hello 'Juan)
(you :wrote :on '(3 Dec 2006 05:27:13 -0800))
(
JR> Would not be fascinating if the evolution of CL was towards a new
JR> standard, clean and specially oriented to web?
yes, it would be fascinating
JR> 4) A new LISP 'dialect' for the web instead Arc, a kind of ISO
JR> standarization of S(cheme)XML with modifications.
yes! :)
JR> Would a ISO standard for an alternative to XML save all of us?
no.
there is ISO standard ISLISP, but it's very dead.
there are no any standards for PHP, but it's very alive.
you can also compare YAML and JSON. both are more sane then XML, and home
some kind of spec. YAML's look more official style (W3C style), but JSON is
2 times more widespread -- because of JavaScript rather then Python and Ruby
behind it. and SXML is 20 times less widespread then YAML, because of Scheme
behind it.
i think the only way you can do to popularize it is a Killer App, rather
than some standards.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> JR> Would a ISO standard for an alternative to XML save all of us?
>
> no.
> there is ISO standard ISLISP, but it's very dead.
> there are no any standards for PHP, but it's very alive.
>
> you can also compare YAML and JSON. both are more sane then XML, and home
> some kind of spec. YAML's look more official style (W3C style), but JSON is
> 2 times more widespread -- because of JavaScript rather then Python and Ruby
> behind it. and SXML is 20 times less widespread then YAML, because of Scheme
> behind it.
>
> i think the only way you can do to popularize it is a Killer App, rather
> than some standards.
Yes i agree that only a standard does not matter. But i thought of the
standard as a formality for a working approach.
I know those you cited. Curiously are popular because alternative to
XML. PHP is prefered over XSLT. YAML is prefered over XML and born from
a group of XML developers tried to correct/admend XML (SML, MinML).
What part of Scheme is unlikely for people who likes Python and Rubi
and JS? I think that are not the (). Python has a lot of more of ()
than Scheme regarding XML docs.
On 2006-12-03 13:27:13 +0000, "Juan R."
<··············@canonicalscience.com> said:
> Would a ISO standard for an alternative to XML save all of us?
No. XML is a done deal. You need to fight next year's battles, not
ones that were decided 5 years ago, even if the technology that won was
crap.
Tim Bradshaw wrote:
> On 2006-12-03 13:27:13 +0000, "Juan R."
> <··············@canonicalscience.com> said:
>
> > Would a ISO standard for an alternative to XML save all of us?
>
> No. XML is a done deal. You need to fight next year's battles, not
> ones that were decided 5 years ago, even if the technology that won was
> crap.
And does not the war W3C/Microsoft/WhatWG fits into that category?
Microsoft's attack to XML will begin next year and even i heard that
they are now interested in functional programming and claim alternative
to Scheme/LISP.
The return of MathML (XML) to HTML was decided just some months ago in
Mozilla comunity.
Ask your colleagues, "what web do you want"?
P.S: I do not want a XML W3C one because fatally flawed and non
elegant. I do not want a new HTML5 with mixture of seudo-XML,
JS+Python+C. I do not want Avalon/XAML+Microsoft languages.
On Mon, 04 Dec 2006 09:16:19 +0100, Juan R.
<··············@canonicalscience.com> wrote:
>
> Tim Bradshaw wrote:
>> On 2006-12-03 13:27:13 +0000, "Juan R."
>> <··············@canonicalscience.com> said:
>>
>> > Would a ISO standard for an alternative to XML save all of us?
>>
>> No. XML is a done deal. You need to fight next year's battles, not
>> ones that were decided 5 years ago, even if the technology that won was
>> crap.
>
> And does not the war W3C/Microsoft/WhatWG fits into that category?
>
> Microsoft's attack to XML will begin next year and even i heard that
> they are now interested in functional programming and claim alternative
> to Scheme/LISP.
>
> The return of MathML (XML) to HTML was decided just some months ago in
> Mozilla comunity.
>
> Ask your colleagues, "what web do you want"?
>
> P.S: I do not want a XML W3C one because fatally flawed and non
> elegant. I do not want a new HTML5 with mixture of seudo-XML,
> JS+Python+C. I do not want Avalon/XAML+Microsoft languages.
>
Well you can't always get what you want. Life is about compromises.
I remember reading Richard Feynman got frustrated with the complicated math
notation in quantum physics and came up with his own.
But since no-one else used it no-one could read what he wrote.
Eventually he went back to standard notation.
I guess I suspect the same outcome in this case.
Most people here agree that XML sucks for many things. It works OK
for formatted text, but for database tables and RDF the amount
of waste is is mind boggling. I see the way of dealing with it more
like what Franz did in AllegroGraph. Read the super-verbose syntax
convert it to more compact and efficient Lisp and then manipulate it.
The result is the most efficient RDF processor out there.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
>
> Well you can't always get what you want. Life is about compromises.
> I remember reading Richard Feynman got frustrated with the complicated math
> notation in quantum physics and came up with his own.
> But since no-one else used it no-one could read what he wrote.
> Eventually he went back to standard notation.
> I guess I suspect the same outcome in this case.
Probably because offered no advantages enough for the change. However,
he developed a third formulation of QM (beyond Schr�dinger and
Heisemberg ones) with clear advantages in the relativistic regime and
that is very popular.
> Most people here agree that XML sucks for many things. It works OK
> for formatted text, but for database tables and RDF the amount
> of waste is is mind boggling.
I think you refer to difference between mixed and pure content. Check
this [*] XML developer says about problems with mixed content XML.
All recent document XML languages (except based in HTML) I revised
avoid mixed markup. For instance Elsevier DTD for scientific docs, ECMA
draft for Office docs, etc. Something like
<p><span>This is some </span><b>bold</b><span> text.</span></p>
is considered to be better design than
<p>This is some <b>bold</b> text.</p>
Elsevier uses an explicit <text> element in CEP with that purpose,
whereas ECMA markup uses <t>, but is more complex with <t> elements
into 'runs'.
Is it not ironic that at the one hand claimed advantages on the
document side whereas in practice people is using XML as a data
language?
Now notice that pure markup is just a verbose version of
(p "This is some " (b "bold") " text.")
> I see the way of dealing with it more
> like what Franz did in AllegroGraph. Read the super-verbose syntax
> convert it to more compact and efficient Lisp and then manipulate it.
> The result is the most efficient RDF processor out there.
Whereas interesting, this does not eliminate most of trouble with XML.
And does not leave the web to a full potential.
I was not thinking in LISP "behind the scenes" but some modification
generalization of LISP could be more popular than HTML is [**].
Apparently from reading messages to this group. Most if not all of
people would find nice a LISP based web but it appears that nobody has
the 'courage' to begin such one project and prefer off-line or
server-like manipulation of standards becoming from W3C and others.
[*]
http://nothing-more.blogspot.com/2006/02/why-is-it-called-markup-language.html
[**] Maybe this is just utopic
On Sun, 03 Dec 2006 14:27:13 +0100, Juan R.
<··············@canonicalscience.com> wrote:
> I am very interested in Internet technologies. I consider that they are
> so an important revolution as transition from mainframes to PCs was in
> the past.
>
> Some time ago, i was newbie and i promoted XML as fascinating future
> for the web (aka comunication).
>
Have you looked at the web support in ACL?
It doesn't reinvent XML but in does allow you to manipulate it as SEXPR's.
Also Action-Script as a alternative to JSP/ASP. Allegro-Serve. Integration
with Java. COM access. MySQL
Support for most web protocols.
Obviously not a web lisp but run from emacs with nxml-mode for xml/xhtml
it works pretty well.
(If for some reason you should want to do real work today.. :) )
WPF (Windows Presentation Foundation aka Avalon) is not supported.
(XAML includes more. Like support for a Business logic language and a
client/server setup language.)
Anyhow at current Windows Expression (available in prerelease for free
from Microsoft) is the only
tool for working with WPF.
RDNZL (from Edi Weitz) provides a rudimentary .NET access so you could use
this to access interfaces
written in XAML I suspect (gotta try that).
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> Have you looked at the web support in ACL?
> It doesn't reinvent XML but in does allow you to manipulate it as SEXPR's.
> Also Action-Script as a alternative to JSP/ASP. Allegro-Serve. Integration
> with Java. COM access. MySQL
> Support for most web protocols.
> Obviously not a web lisp but run from emacs with nxml-mode for xml/xhtml
> it works pretty well.
> (If for some reason you should want to do real work today.. :) )
>
> WPF (Windows Presentation Foundation aka Avalon) is not supported.
> (XAML includes more. Like support for a Business logic language and a
> client/server setup language.)
> Anyhow at current Windows Expression (available in prerelease for free
> from Microsoft) is the only
> tool for working with WPF.
> RDNZL (from Edi Weitz) provides a rudimentary .NET access so you could use
> this to access interfaces
> written in XAML I suspect (gotta try that).
>
But i was asking for an unified approach. No a collection of different
tools but a "XML web without XML".
From: Christian Haselbach
Subject: Re: Future of LISP. Alternative to XML. Web 3.0?
Date:
Message-ID: <ekvhav$bgu$1@online.de>
Juan R. schrieb:
> When you do intensive research and usage of XML you find very
> disturbing stuff in the XML design. For instance that contrary to
> common sense the first child in
>
> <book>
> <title>$$$</title>
> <author>----</author>
> </book>
>
> is *not* the title element!
Yes, but the css selector "book title:first-child" matches the
title element. Wonderful, isn't it? I just spend the last day
writing a function that retrieves elements by CSS selector in
Javascript.
> Contrary to P. Graham i do not think that future of LISP would be just
> a new dialect [2]. I think that a more fascinating future would be an
> web-based LISP.
You mean something like HOP? http://hop.inria.fr/
While I think, HOP is very interesting, it concentrates on a
specific problem domain. There is nothing wrong with that,
but I doubt it would yield a general purpose language (despite
the fact that it is of course turing complete).
Regards,
Christian
Christian Haselbach wrote:
> Juan R. schrieb:
> > When you do intensive research and usage of XML you find very
> > disturbing stuff in the XML design. For instance that contrary to
> > common sense the first child in
> >
> > <book>
> > <title>$$$</title>
> > <author>----</author>
> > </book>
> >
> > is *not* the title element!
>
> Yes, but the css selector "book title:first-child" matches the
> title element. Wonderful, isn't it? I just spend the last day
> writing a function that retrieves elements by CSS selector in
> Javascript.
But i was saying that the first child of <book> is not <title>. WS
processing is one of well-known nightmares of XML. Any advanced XML DTD
just ignores mixed markup.
> > Contrary to P. Graham i do not think that future of LISP would be just
> > a new dialect [2]. I think that a more fascinating future would be an
> > web-based LISP.
>
> You mean something like HOP? http://hop.inria.fr/
> While I think, HOP is very interesting, it concentrates on a
> specific problem domain. There is nothing wrong with that,
> but I doubt it would yield a general purpose language (despite
> the fact that it is of course turing complete).
That is defined as new programming language for web 2.0. I mean unified
approach: Server PL + client scripting + docs + data + style + ...
Moreover, i do not really understand the double syntax of tags more
strings.
HTML:
<HTML>
<BODY>
<B>A plain text</B>
</BODY>
</HTML>
Hop:
(<HTML>
(<BODY>
(<B> "A plain text")))
S(cheme)XML:
(HTML
(BODY
(B "A plain text")))
Python (SLiP):
HTML():
BODY():
B(): "A plain text"
Why could not a future LISP address this as alternative to XML?
From: Christian Haselbach
Subject: Re: Future of LISP. Alternative to XML. Web 3.0?
Date:
Message-ID: <el270q$ur9$1@online.de>
Juan R. schrieb:
> But i was saying that the first child of <book> is not <title>. WS
And I said, that you are correct.
Regards,
Christian
On Sun, 03 Dec 2006 23:01:55 +0100, Christian Haselbach wrote:
> You mean something like HOP? http://hop.inria.fr/
> While I think, HOP is very interesting, it concentrates on a
> specific problem domain. There is nothing wrong with that,
> but I doubt it would yield a general purpose language (despite
> the fact that it is of course turing complete).
Thanks for that link! I became a Serrano fan a couple of years ago, when
I discovered Skribe. Seems he's gone on to bigger and better things.
I have a basic question for the group, though: what is the attraction for
writing applications that are even slower and more cumbersome than can be
achieved with Java applets? I suppose that one day the javascript
interpreters in web browsers will grow the whole just-in-time native code
thing, so that this stuff works acceptably, buy why even go there in the
first place, when Java applets were obviously such a huge hit, despite
being much more compact to download, and running at (these days)
essentially native-code performance?
(Yes, I'm a confused embedded DSP programmer who wants to write a GUI front
end for something, for the first time. Doing the web-app thing is one of
the avenues I'm considering, but I had been planning to use Java up to
now. If there's a good argument for it, I could try hop too/instead...)
Cheers/thanks,
--
Andrew
On Mon, 04 Dec 2006 01:38:59 +0000, Andrew Reilly wrote:
> I have a basic question for the group, though: what is the attraction
> for writing applications that are even slower and more cumbersome than
> can be achieved with Java applets? I suppose that one day the
> javascript interpreters in web browsers will grow the whole just-in-time
> native code thing, so that this stuff works acceptably, buy why even go
> there in the first place, when Java applets were obviously such a huge
> hit, despite being much more compact to download, and running at (these
> days) essentially native-code performance?
I'd consider Java Web Start instead of Java applets:
http://java.sun.com/products/javawebstart/
--
Lars Rune Nøstdal
http://nostdal.org/
Hi Lars,
On Mon, 04 Dec 2006 03:29:24 +0100, Lars Rune Nøstdal wrote:
> I'd consider Java Web Start instead of Java applets:
Well, sure. I suppose that is what I'd do: get to use the latest Swing
GUI elements.
Doesn't answer the question, though: why do all of that in a messier,
slower, more painful way (Web-2.0/Ajax/etc)? What's the upside? Is it
*just* to avoid requiring an up-to-date JVM on the browser side? [vs
having an appropriately up-to-date browser, etc.]
Cheers,
--
Andrew
On Mon, 04 Dec 2006 04:06:59 +0000, Andrew Reilly wrote:
> Hi Lars,
>
> On Mon, 04 Dec 2006 03:29:24 +0100, Lars Rune Nøstdal wrote:
>
>> I'd consider Java Web Start instead of Java applets:
>
> Well, sure. I suppose that is what I'd do: get to use the latest Swing
> GUI elements.
>
> Doesn't answer the question, though: why do all of that in a messier,
> slower, more painful way (Web-2.0/Ajax/etc)? What's the upside? Is it
> *just* to avoid requiring an up-to-date JVM on the browser side? [vs
> having an appropriately up-to-date browser, etc.]
I think so. Using the browser as a client you get to reach a _lot_ of
people but I believe it is a mistake to assume people are not willing to
download an application like a word-processor or similar if you use that
browser to inform about your new word-processor instead of trying to
embed it in it. Using a solution like - or similar to Java Web Start, the
problem of keeping clients up to date is gone so that is no argument
against doing it the "application way" either.
I've generally given up on Web-2.0/Ajax as a reliable and lasting
solution; I'm tired of not being in control of the client-side. I'm
thinking especially of IE here; but FF is not something I am able to fix
bugs in either - and in general the whole JS/XML/DOM/HTML-thing is just
plain ugly and painful in the first place.
It's too much work for front-ends; something that in many cases should
be the simple part of a project.
What I'd prefer in Web-3.0 is throwing all the bloated and stupid
standards that no-one follows anyway out the window(!) - then get W3C to
develop or support a portable Open Source small VM-thing for rich
client-work instead; maybe something based on Java (which is going Open
Source now). But it has got to have support for "script-style" development
too.
--
Lars Rune Nøstdal
http://nostdal.org/
Lars Rune Nøstdal wrote:
> I've generally given up on Web-2.0/Ajax as a reliable and lasting
> solution; I'm tired of not being in control of the client-side. I'm
> thinking especially of IE here; but FF is not something I am able to fix
> bugs in either - and in general the whole JS/XML/DOM/HTML-thing is just
> plain ugly and painful in the first place.
Specially when you need non-mainstream stuff, then no cross-browser
compatible website can be generated.
> What I'd prefer in Web-3.0 is throwing all the bloated and stupid
> standards that no-one follows anyway out the window(!)
Example: XHTML 2. No browser follows W3C developments here and they
joined into the WhatWG and developed HTML5 as alternative. Without
browser interest XHTML 2 is unuseful. The same about XSL-FO or XForms.
> - then get W3C to
> develop or support a portable Open Source small VM-thing for rich
> client-work instead; maybe something based on Java (which is going Open
> Source now). But it has got to have support for "script-style" development
> too.
The W3C is not more credible as web director [*].
Mozilla, Opera, Apple, and Google join into WhatWG. Google is very
interested in Python.
Microsoft is developing XAML and collaborates with ECMA standards body
for XML Office docs.
What wil be the role of LISP community, a hundred of disconected
personal/academic approaches?
For instance, still the LISP community has no standard way to encode
<tag key='value'>content</tag>
Juan R. <··············@canonicalscience.com> wrote:
+---------------
| For instance, still the LISP community has no standard way to encode
| <tag key='value'>content</tag>
+---------------
True, we do have multiple approaches, but only a fairly small
number, each one having arisen according to a particular need
not entirely solved by the others:
((tag key "value") "content") ; The classic first attempt.
((:tag :key "value") "content") ; Avoids some naming conflicts.
(:tag (:key "value") "content") ; Can be easier for humans to read.
(:tag :key "value" "content") ; Ditto, but needs a NIL before
; content iff content starts with
; a naked keyword.
<tag :key "value" | content> ; [TML] Avoids string quotes and
; appeases parenthephobes.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Juan R. <··············@canonicalscience.com> wrote:
> +---------------
> | For instance, still the LISP community has no standard way to encode
> | <tag key='value'>content</tag>
> +---------------
>
> True, we do have multiple approaches, but only a fairly small
> number, each one having arisen according to a particular need
> not entirely solved by the others:
>
> ((tag key "value") "content") ; The classic first attempt.
> ((:tag :key "value") "content") ; Avoids some naming conflicts.
> (:tag (:key "value") "content") ; Can be easier for humans to read.
> (:tag :key "value" "content") ; Ditto, but needs a NIL before
> ; content iff content starts with
> ; a naked keyword.
> <tag :key "value" | content> ; [TML] Avoids string quotes and
and more!
DSSSL: (tag key: "value" "content")
S(cheme)XML: (tag (@ (key "value")) "content")
GSXML: (tag (@key "value") "content")
> ; appeases parenthephobes.
>
Note that SLiP (Python) uses parentheses also:
tag(key="value"): "content"
the XHTML
<b>this is bold</b>
is
tag(): "this is bold"
and
(tag "this is bold")
Therein i think that parentheses cannot be main fobia about LISP
(except by misinformed people).
The question is, what role the LISP community want to play in three
next years? 'Passive' or 'active'?
On Mon, 04 Dec 2006 08:52:43 +0100, Lars Rune Nøstdal wrote:
> But it has got to have support for "script-style" development too.
What I mean here - I think, it that there has got to be a runtime
compiler/jit-thing available at the client also; not just a VM.
--
Lars Rune Nøstdal
http://nostdal.org/
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Future of LISP. Alternative to XML. Web 3.0?
Date:
Message-ID: <REM-2006dec04-003@Yahoo.Com>
> From: "Juan R." <··············@canonicalscience.com>
(XML:)
> <section>
> <title>Introduction to LISP</title>
> <para>In this section, we will see the formal properties of
> S-EXPR...</para>
> ...
> </section>
> becomes
> (section
> (title "Introduction to LISP")
> (para "In this section, we will see the formal properties of
> S-EXPR...")
> ...
> )
Yes. I've advocated something like that for quite some time. Except
I'm more interested in directly replacing XML&RMI for distributed
computing, rather than directly replacing HTML for Web pages.
Unfortunately I never knew anyone else interested in the same idea
willing to work with me to develop distributed computing (over HTTP
initially) based on this notation for structured-data messages.
It seems to me we need to think of some useful service that
somebody might want to use, and then implement it with s-expr
instead of XML representation for queries and responses. Then we
can decide the precise s-expressions to be involved, and then write
a demonstration server, and use a regular Web browser to test it
remotely. Do you have any good ideas of such first services to
offer as demos?
Robert Maas, see http://tinyurl.com/uh3t wrote:
> Yes. I've advocated something like that for quite some time. Except
> I'm more interested in directly replacing XML&RMI for distributed
> computing, rather than directly replacing HTML for Web pages.
> Unfortunately I never knew anyone else interested in the same idea
> willing to work with me to develop distributed computing (over HTTP
> initially) based on this notation for structured-data messages.
Did you check [1]?
> It seems to me we need to think of some useful service that
> somebody might want to use, and then implement it with s-expr
> instead of XML representation for queries and responses.
S-expr are more concise and easy to parse than XML. You would note
improvements when dealing with high volume traffic sites or
manipulating large files.
> Then we
> can decide the precise s-expressions to be involved, and then write
> a demonstration server, and use a regular Web browser to test it
> remotely. Do you have any good ideas of such first services to
> offer as demos?
Not sure if are good or crazy ideas:
For today LISP
1) Still now, there is not standard s-expr representation for <tag
attribute='value'>content</tag>. Each LISP project is reinventing the
wheel and that is not good. A standard s-expr for encoding XML (HTML)
format *is* needed.
2) Once you can match any XML/HTML you can work any project you desire.
For instance, there are plans to add an editing syntax for XUL. And
they also looked for LISP. XUL will be fundamental piece for rich web
applications based in Mozilla clients [2]. LISP could be a good way to
write LISP-XUL applications after are converted into pure XML and run
by XUL engine.
It would be more cool if Mozilla run directly the LISP code but I wait
not that motion from Mozilla people.
XSLT is a popular tool for basic XML transformations. It is very
verbose and limited in funcionality but people is living with that. A
point where XSLT templates are very poor is in transformation to highly
structured XML nodes from unstructured inputs. E.g. you can see many
XML to HTML templates because the XML file contain more information
than the final HTML, but i see none LaTeX to MathML template.
These kind of highly specialized conversions are very important -XSLT
people just discovered and XSLT 2 extends funcionality to those but the
spec is not popular and Microsoft rejected it- and would be cheap in
LISP.
For tomorrow LISP
I agree with Graham that LISP is asking for an update. Some
modifications I am interested or working on include
3) Documentation. XML was designed for documents, S-expr for data.
There are several documentation systems based in s-expr (e.g. Scribe),
but failed to be popular when compared with acceptance of HTML or TeX.
They failed because were not designed for that kind of task.
IMHO, we would modify the syntax for success on documentation oriented
tasks. I propose something like [3]
[#p This is [#b bold]]
instead
(p "This is " (b "bold"))
for
<p>This is <b>bold</b></p>
Note the surface similarity with TeX syntax
{\p This is {\b bold}}
The usage of square brackets and sharps is because readability and
writability issues.
It is very easy to parse and more concise and readable (arguably) than
LISP. What about forums and blogs?
In PHP-based forums i use stuff like [b]bold[/b] when posting, On html
blogs, i can omit some end tags. The situation is poor with xhtml blogs
because well-formedness requirement.
It is boring just typing all of those </li>, </p>, </blockquote>,
</strong> when are adding _nothing_ to your comment not to the blog
database. What is the rationale for forcing end tags in a DTD defined
language as XHTML?
I wait to promote this kind of syntax for blogs, phorums, and wikis. It
is a very young project. There is not formal spec not implementation
and still has attracted a lot of attention. Even it has been suggested
by a MathML WG author that this could be input syntax for next MathML
3.
For beyond LISP. Arc?
4) Avoid prefix mathematics
It has been suggested that prefix mathematics is the main flaw of
s-expr. It is not a question of familiarity but of readability. P.
Graham recognizes that he still find disturbing the prefix notation for
complex pieces of math.
Prefix notation is firmly based in underlying data representation,
therein that any attempt to an infix LISP has failed during decades and
I suppose we would wait the same for Arc proposal.
I am not claiming for an infix input surface (infix (2 + 3)) expanding
to underlying (+ 2 3) like Peter Norvig suggests for next LISP, but for
a built-in infix LISP with prefix and postfix as special cases:
[prearguments #operator postarguments]
[#operator postarguments]
[prearguments #operator]
Yes, this would break with (function.arguments) and maybe would not be
called LISP anymore, but apparently this is the kind of Arc dialect
that some people wait.
[1] http://theory.lcs.mit.edu/~rivest/sexp.txt.
[2] http://xul.sourceforge.net/compact.html
[3] See CanonML listed already in four place in XML alternatives site
(http://www.pault.com/xmlalternatives.html).
"Juan R." <··············@canonicalscience.com> writes:
> It has been suggested that prefix mathematics is the main flaw of
> s-expr. It is not a question of familiarity but of readability. P.
> Graham recognizes that he still find disturbing the prefix notation for
> complex pieces of math.
>
> Prefix notation is firmly based in underlying data representation,
> therein that any attempt to an infix LISP has failed during decades and
> I suppose we would wait the same for Arc proposal.
This is just a matter of opinion. Although there are some
mathematical expressions that look unavoidably hairy with prefix
notation, it can often make the calculation itself clearer by grouping
the arguments under the operator and letting you rely on indentation
to see the structure of a calculation.
For example, I find
(setf useless-temperature-sum
(+ (temperature san-francisco)
(temperature new-york)
(* (temperature des-moines) 1.2)
34))
to be much easier to read than the same infix expression. (YMMV?)
Keep in mind that Graham also really likes one- or two-letter variable
idenitifiers, so that could influence his views on using prefix
notation with mathematical expressions - a bunch of single-character
identifiers are easily confused with operators.
There is an infix package for Common Lisp, although I don't remember
where it is. Try googling for "infix.lisp."
Bill Atkins wrote:
> This is just a matter of opinion. Although there are some
> mathematical expressions that look unavoidably hairy with prefix
> notation, it can often make the calculation itself clearer by grouping
> the arguments under the operator and letting you rely on indentation
> to see the structure of a calculation.
>
> For example, I find
>
> (setf useless-temperature-sum
> (+ (temperature san-francisco)
> (temperature new-york)
> (* (temperature des-moines) 1.2)
> 34))
>
> to be much easier to read than the same infix expression. (YMMV?)
> Keep in mind that Graham also really likes one- or two-letter variable
> idenitifiers, so that could influence his views on using prefix
> notation with mathematical expressions - a bunch of single-character
> identifiers are easily confused with operators.
I wannot begin a debate about prefix and infix and about if your code
is more or less readable [*]. Simply note i can duplicate your code,
therefore if you are happy working in a prefix way no problem with this
new syntax, except that i used [ and ]. I do not force prefix as LISP
does.
> There is an infix package for Common Lisp, although I don't remember
> where it is. Try googling for "infix.lisp."
Yes, i know several infix macros and studied even 'true' infix lisp
approaches: MLISP, PLASMA... All failed during decades.
It is supposed that Arc will also use infix mathematics. I suppose
would fail so much as M-expr did decades ago.
[*] I use large identifiers also: temperature, time, energy,
concentration...
Juan R. wrote:
> I am not claiming for an infix input surface (infix (2 + 3)) expanding
> to underlying (+ 2 3) like Peter Norvig suggests for next LISP, but for
> a built-in infix LISP with prefix and postfix as special cases:
>
> [prearguments #operator postarguments]
>
> [#operator postarguments]
>
> [prearguments #operator]
>
> Yes, this would break with (function.arguments) and maybe would not be
> called LISP anymore
Here is an idea: Call it Smalltalk.
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/
Pascal Costanza wrote:
> Juan R. wrote:
>
> > I am not claiming for an infix input surface (infix (2 + 3)) expanding
> > to underlying (+ 2 3) like Peter Norvig suggests for next LISP, but for
> > a built-in infix LISP with prefix and postfix as special cases:
> >
> > [prearguments #operator postarguments]
> >
> > [#operator postarguments]
> >
> > [prearguments #operator]
> >
> > Yes, this would break with (function.arguments) and maybe would not be
> > called LISP anymore
>
> Here is an idea: Call it Smalltalk.
I do not usually chose same names for unrelated stuff. But it would be
noted that special construct [#operator postarguments] can be managed
in very similar way to (function.arguments) and could be done
equivalent with an intermediate layer to CL/Scheme. I think that any
LISP form has an equivalent form
[#PLUS 2 3] <---> (PLUS 2 3)
It is interesting also that general form [prearguments #operator
postarguments] is close to rationale for the generalization (annotation
function.arguments) suggested for next 'LISP' i.e. Arc.
Juan R. wrote:
> Pascal Costanza wrote:
>> Juan R. wrote:
>>
>>> I am not claiming for an infix input surface (infix (2 + 3)) expanding
>>> to underlying (+ 2 3) like Peter Norvig suggests for next LISP, but for
>>> a built-in infix LISP with prefix and postfix as special cases:
>>>
>>> [prearguments #operator postarguments]
>>>
>>> [#operator postarguments]
>>>
>>> [prearguments #operator]
>>>
>>> Yes, this would break with (function.arguments) and maybe would not be
>>> called LISP anymore
>> Here is an idea: Call it Smalltalk.
>
> I do not usually chose same names for unrelated stuff.
It was a tongue-in-cheek remark. The syntax you're suggesting is very
close to the syntax Smalltalk already has. Maybe that's the language
you're looking for.
Although computer science is still a very young discipline, it's already
old enough that it's hard to come up with new idea that haven't been
tried before.
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/
Pascal Costanza wrote:
> Juan R. wrote:
> >
> > I do not usually chose same names for unrelated stuff.
>
> It was a tongue-in-cheek remark. The syntax you're suggesting is very
> close to the syntax Smalltalk already has. Maybe that's the language
> you're looking for.
I think that there is nothing in common. Smalltalk uses [ and ] for
blocks (anonymous functions) and # for 'symbols'. That is not the case
here!
What is more the Smalltalk #(1 2 3 4) has no sense here.
Note that instead
[#b important]
i could define the syntax to be
{\b important}
and would _look_ close to TeX
{\b important}
but there is nothing in common between both: there is not TeX reserved
words in the first, the WS rules are absolutely different, the
attribute model is completely different, the first {} is a list the
second {} is a sequence of tokens, etc.
> Although computer science is still a very young discipline, it's already
> old enough that it's hard to come up with new idea that haven't been
> tried before.
This sound too negative. In the markup community -is where i begin all
of this- the approach already got more weight than similar mature
approaches becoming from lisp or scheme: MNL, SXML, Scribe, Skribe,
Latte...
I proposed LISP as input syntax for mathml. Nobody agreed.
I did not propose CanonML syntax but in mails i am receiving "Do you
use the same syntax for all elements? I mean [#elementName content]. If
so it should not be difficult to write converter to XML/HTML/OMML.
Something in this mood could also work as input syntax for
MathML too, ..."
Another guy found the syntax cool and even did a suggestion for
attributes syntax.
Currently, the CanonML syntax is extensible and solid enough i can
*duplicate* Python and LISP/Scheme program in a CanonML doc.
Therefore... Time will say.
Juan R. wrote:
> Pascal Costanza wrote:
>> Juan R. wrote:
>>> I do not usually chose same names for unrelated stuff.
>> It was a tongue-in-cheek remark. The syntax you're suggesting is very
>> close to the syntax Smalltalk already has. Maybe that's the language
>> you're looking for.
>
> I think that there is nothing in common.
That's because you're only looking at the very superficial level.
Smalltalk has two kinds of syntaxes: unary messages and binary messages.
This comes pretty close to what you have suggested.
Whether there are angle brackets, square brackets or curly braces around
such expressions doesn't really matter.
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/
Pascal Costanza wrote:
> Juan R. wrote:
> > Pascal Costanza wrote:
> >> Juan R. wrote:
> >>> I do not usually chose same names for unrelated stuff.
> >> It was a tongue-in-cheek remark. The syntax you're suggesting is very
> >> close to the syntax Smalltalk already has. Maybe that's the language
> >> you're looking for.
> >
> > I think that there is nothing in common.
Well my previous reply was exagerated. They use 2 as symbol for the
concept of number 2 in the syntax, we also. Therefore, you always can
find a common denominator between both syntaxes.
> That's because you're only looking at the very superficial level.
> Smalltalk has two kinds of syntaxes: unary messages and binary messages.
> This comes pretty close to what you have suggested.
I do not think so. Asymmetry between receiver and argument; the :
notation disambiguating keyword binary messages; the pseudo-stack
evaluation of messages; there is not [*] multiple messages concept
matching the 'multimarkup' idea because Alpha:Beta: is not equivalent
to #Alpha#Beta; the unitary [*] evaluation of messages by receivers;
precedence rules for n-ary messages; and others appears to me to be
fundamental differences unless whereas I continue thinking that i would
not call tigers to cats.
> Whether there are angle brackets, square brackets or curly braces around
> such expressions doesn't really matter.
Water <plus 2 3 />
and
LISP (PLUS 2 3)
are different to code [#PLUS 2 3] even when looking 'close'.
It is not just a matter of choosing a type of brackets. For instance,
the lisp "(" are function applications and, therefore, needing
quotation whereas do not need in "[". Therefore it is a bit more than
just conversion from < /> or ( ) to [ ].
It is not crazy to think of cnml expressions as a kind of superset of
LISP ones.
[*] So far as i know.
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Future of LISP. Alternative to XML. Web 3.0?
Date:
Message-ID: <REM-2006dec07-001@Yahoo.Com>
> From: "Juan R." <··············@canonicalscience.com>
> Did you check [1]?
> [1] http://theory.lcs.mit.edu/~rivest/sexp.txt.
Just now, in preparation for responding to your posting.
It has some rough edges. For example, when I saw /<carriage-return>
I didn't realize it meant literally the cr character within the
message, I thought the textual string <carriage-return> literally
appeared, and I hoped it would be later explained *which* carriage
returns (later) would be ignored and when the ignoring of them
would be turned back off. Then the examples just had nothing at
all, just a new-line situation, with no explanation what was
supposed to be there. Apparently what's there is the option of the
local implementation, and regardless of which of the four choices
applies, a backslant at the end of the line causes that line to be
directly adjacent to the start of the next line ignoring whichever
of the four types of newline happened to be present. That ought to
be explained a little, instead of leaving it to the reader to guess
what is meant.
Also the BNF has semicolons at the ends of some lines but not
others, and I have no idea what those semicolons denote. I'm pretty
sure they aren't supposed to be literally present in the syntax
being defined?
> > It seems to me we need to think of some useful service that
> > somebody might want to use, and then implement it with s-expr
> > instead of XML representation for queries and responses.
> S-expr are more concise and easy to parse than XML. You would note
> improvements when dealing with high volume traffic sites or
> manipulating large files.
That's not the point I was making. If somebody implements a server
that merely duplicates an already-available service, except for
using s-expressions instead of XML, nobody is going to use it,
because it's cheaper to keep the existing XML software and continue
paying for extra bandwidth rather than rewrite all the software
just to save a fraction on the bandwidth.
We need a brand-new service that somebody might want to use, which
isn't already provided via XML, so somebody would have incentive
play with it manually to get a feel for the service offered and to
*see* how incredibly more legible and significantly more efficient
it is compared to XML, and then having seen that they might be
willing to download our new s-expression plugin for
distributed-computing API so that their software could then use XML
or s-expressions equally. Note that our server could provide output
in three modes, fully prettyprinted, typical-compact prettyprinted,
and ultra-compact, making it easy to switch between
debugging/explanatory mode and maximal-efficient mode.
As an alternative to a brand-new service, one hack I have been
thinking about from time to time is to get permission to use
Google's XML interface to their search engine, then write an
interface that maps between s-expressions and XML, so somebody
could connect to my CGI application, submit Google searches in
s-expression format, and get back RMI objects/references in
s-expression format, and then browse the RMI objects remotely via
my service. As a distributed application, for my own personal use,
I could write an s-expression client that submitted a Google search
via my s-expression interface, then browsed the resultset to
organize it better, then finally presents the nicely re-organized
index of search results as a tree of virtual Web pages for me to
browse from a regular Web browser.
One specific application I urgently need is a smart way to find
where people have posted followups to what I posted, collecting
them all in tree format, and checking off when I've already looked
at some article and decided I'm done with it. I could do that
directly locally by writing a HTML parser and parsing the results
from Google Groups search, or I could write the HTML parser coupled
to an s-expression interface, and then do all the rest of the work
with s-expression RPC, or I could get permission to use their XML
interface, write XML parser and s-expression interface etc.
> 1) Still now, there is not standard s-expr representation for <tag
> attribute='value'>content</tag>. Each LISP project is reinventing
> the wheel and that is not good. A standard s-expr for encoding XML
> (HTML) format *is* needed.
Do *any* of those LISP projects have a (HTTP-accessible) server I
can play with, to see their various encodings of XML, to compare
them? My position is that first we let a thousand flowers bloom,
then we compare them, then we pick the prettiest. If the flowers
already have bloomed, I want to see them now. If they haven't yet
bloomed, then what's taking them so long?
> It would be more cool if Mozilla run directly the LISP code ...
Note: I'm more interested in s-expressions replacing the XML as
used in distributed computing, rather than replacing the XHTML used
to replace SGML-HTML for Web pages. So Mozilla running the LISP
code seems moot. Normally Mozilla would connect to a CGI or JSP
application, as the toplevel user interface for some distributed
application, and it's only within that application that connections
would be made to other InterNet hosts and XML or s-expressions
would be exchanged.
The only reason I suggest running s-expressions on top of HTTP is
to make it easy to get access to such services for interactive play
just by using an existing Web browser instead of having to write a
whole new client program. I.e. I would pretend to be part of the
distributed application, calling some HTTP-accessible service as if
I were making a RPC/RMI call. Even later if I have written my own
client to make such calls, still for debugging it'd be nice to be
able to switch back to manual calls from a regular Web browser.
> I agree with Graham that LISP is asking for an update. Some
> modifications I am interested or working on include
Do you really mean modification (incompatible changes), or merely
enhancements/additions?
> 3) Documentation. XML was designed for documents, S-expr for data.
But documents *are* (one kind of) data!
S-expressions have already been used to represent lots of different
kinds of data. Surely they can also represent documents.
> There are several documentation systems based in s-expr (e.g. Scribe),
> but failed to be popular when compared with acceptance of HTML or TeX.
Both HTML and TeX suck when it comes to expressing mathematics.
Compare these two ways of expressing the same thing:
(expt (arrayelement x 5) 2)
x superscript 2 backspace subscript 5 endelement
Can you see that s-expressions clearly show the nesting of
mathematical notation, whereas TeX acts like a manual typewriter
moving head up or down with no reference to what the mathematics is
supposed to really mean?
2
x
5
Is that even possible to express in HTML?
By the way, way back in 1975 I wrote a crude text-layout program
(MRPP3 a.k.a. POX, successor to something (MRPPP and MRPP2) I had
written in 1969-70), which had overlays (composible pieces of
picture which could then be combined in various geometric
arrangements to make larger pictures), and macros (syntax vaguely
like Algol/MacSyma when called, defined usually to build overlays
out of pieces). Bill Gosper wrote a dandy set of macros for his own
use, enabling him to use my program to lay out immense continued
fractions and matrices and hypergeometric series etc., not as
pretty font-wise as Knuth's carefully tuned Tex, but properly
structured per the nested mathematical expressions.
Later, using PSL (Portable Standard Lisp), I re-wrote the program
(now MRPP4) to work directly from Lisp nested-lists, basically
using the same internal representation as Tony Hearn's "Reduce",
producing output in several formats (ASCII-art, and IBM CRTs
attached to VM/CMS system, and Unix workstations using X),
including a visual interactive structure editor where the cursor
covered an entire sub-expression, shown as that part of the display
highlighted, and could be zoomed in or out and panned up or down
the current level of structure, and then a command could be
executed on the current sub-expression as embedded in the larger
expression to perform algebraic manipulations.
MacSyma used a vaguely similar internal representation to Reduce, a
bit more ugly in my opinion. But in any case, the basic idea is
that internal Lisp structures were used to represent mathematical
documents, and then of course PRINT could externalize such data and
READ could get stuff back in, and MRPP4 could render the data
structures in the usual mathematical-notation format. (MacSyma also
had a math-format display mode, which it normally used for all
output in the ordinary Read-MathEvaluate-Print loop. AFAIK MacSyma
display output provided *only* ASCII-art mode, but I'm probably
mistaken.)
Anyway, one application I'm thinking of writing is a port of MRPP4
to CGI/CMUCL, whereby s-expressions from the client get
internalized to Lisp structures and then displayed as
MRPP4/MacSyma-style ASCII art, using <pre>...</pre> of course to
make sure things line up in all browsers. Of course I'd also have
an output mode for box-diagrams showing how the internal data is
structured. The math-display output would work only for valid math
structures, whereas the box-diagrams would work for all Lisp data.
OK, I've gotten to the part where you mentionned [3], but I had
skipped the section that mentionned [2], so now I went back and
found:
> XUL will be fundamental piece for rich web applications based in
> Mozilla clients [2].
> [2] http://xul.sourceforge.net/compact.html
Yeah, I skipped that because I'm not interested in details of
Mozilla-specific addons/plugins/whatever. But now I looked at that
Web page, and it seems to have some good ideas. I think all the
options except Lisp suck, but it's probably nice to offer the other
formats for people who are stubborn and refuse to use s-expression
notation, so their stuff and our stuff can be easily exchanged in a
standard way. It would be nice if that author would write a
description of an algorithm for converting between XML and the
other notations. Maybe all that is needed is a tree-diagram showing
how XML forms a tree and then how to express that same tree in each
of the other formats being proposed. Using a visual tree as an
intermediary, instead of a pure BNF description, seems best.
(For definition, use a separate visual tree for each BNF
production, showing under the tree the XML and four alternative
notations for that same tree. Then as an example build a nested
tree that uses several of the various productions within it.)
Now back to where I was reading when I saw reference to [3]:
> IMHO, we would modify the syntax for success on documentation
> oriented tasks. I propose something like [3]
> [3] See CanonML listed already in four place in XML alternatives
> site (http://www.pault.com/xmlalternatives.html).
CanonML CanonML is a canonical language trying to offer the best of
different formal, scripting and markup languages. As a formal language
CanonML is based in a modification of S-expressions of SXML.
-> <http://canonicalscience.blogspot.com/2006/04/
canonml-markup-language-beyond-tex-xml.html>
If XML is so fine, why do
we see many alternatives (order of 100) improving its defects and
limitations?
Indeed! With 100 proposed, I would expect to see live
Web-accessible demos of at least twenty of them already.
Do you know of any such?
SXML provides a representation for XML documents in the Scheme
programming language -a kind of dialect of LISP-.
Is that really true, presumably some specialized Scheme notation
that is incompatible with Common Lisp?
I reserved the sequence :: for the tags because is "never" used in
real practice.
Except in its own documentation of course! As a followup to MRPP3,
I envisioned a flexible syntax for quoting strings, where *any*
character could appear verbatum inside a string providing that
portion of the string was delimited by something other than the
particular characters within it. For example, if we allow all of
these ways to quote text: <> [] {} "" '' || %%
then we can include that line of text in verbatim pieces such as:
"these ways to quote text: <> [] {}"[ "" '' || %%]
Note it's broken into two pieces, one quoted by "" but not
containing any internal double-quote marks, and one quoted by []
but not containing any square-brackets. So if some author never
used a particular character (or its mirror image) in an entire
document, he could quote the entire document as one piece by
choosing that particular string-delimiting character pair. I
dislike the idea of a priori decision that "nobody ever" uses a
particular character or character-sequence so it's fine to reserve
it for syntax and require special quoting if that character or
sequence were ever to occur within a document.
OK, enough of that!
At one point you said that [...] is more legible than (...), or
that's what you seemed to say. I would have no objection to a
syntax for s-expressions that made that substitution. In that case,
per my proposed extension from MRPP3 for quoting strings, () would
then be available instead of [] as one of the several available
ways to quote strings. No big deal.
Robert Maas, see http://tinyurl.com/uh3t wrote:
>
> Just now, in preparation for responding to your posting.
> It has some rough edges. For example, when I saw /<carriage-return>
> I didn't realize it meant literally the cr character within the
> message, I thought the textual string <carriage-return> literally
> appeared, and I hoped it would be later explained *which* carriage
> returns (later) would be ignored and when the ignoring of them
> would be turned back off. Then the examples just had nothing at
> all, just a new-line situation, with no explanation what was
> supposed to be there. Apparently what's there is the option of the
> local implementation, and regardless of which of the four choices
> applies, a backslant at the end of the line causes that line to be
> directly adjacent to the start of the next line ignoring whichever
> of the four types of newline happened to be present. That ought to
> be explained a little, instead of leaving it to the reader to guess
> what is meant.
> Also the BNF has semicolons at the ends of some lines but not
> others, and I have no idea what those semicolons denote. I'm pretty
> sure they aren't supposed to be literally present in the syntax
> being defined?
Why do not ask him directly? http://theory.lcs.mit.edu/~rivest/
> > S-expr are more concise and easy to parse than XML. You would note
> > improvements when dealing with high volume traffic sites or
> > manipulating large files.
>
> That's not the point I was making. If somebody implements a server
> that merely duplicates an already-available service, except for
> using s-expressions instead of XML, nobody is going to use it,
> because it's cheaper to keep the existing XML software and continue
> paying for extra bandwidth rather than rewrite all the software
> just to save a fraction on the bandwidth.
This is a case-by-case. It depends of the cost of the XML software
being used and of the cost of the extra bandwidht and/or server disk
and processing time.
In [1] you can find an example of s-expr instead XML for military data.
He claims reduction in a factor of 4.
Others in newsgroup could offer you more help and examples that i can.
> We need a brand-new service that somebody might want to use, which
> isn't already provided via XML, so somebody would have incentive
> play with it manually to get a feel for the service offered and to
> *see* how incredibly more legible and significantly more efficient
> it is compared to XML, and then having seen that they might be
> willing to download our new s-expression plugin for
> distributed-computing API so that their software could then use XML
> or s-expressions equally. Note that our server could provide output
> in three modes, fully prettyprinted, typical-compact prettyprinted,
> and ultra-compact, making it easy to switch between
> debugging/explanatory mode and maximal-efficient mode.
Something somewhat similar i am trying to do for CanonML for scientific
and mathematical data.
For instance, something like [a / 2] is left at editing and storing
mode (you call "ultra-compact"). At this representation one typically
saves 10x over typical XML encoding. Next, it can be parsed to [#fract
[#num a] [#den 2]] for 'prettyprinted'.
Current browsers do not understand this code, but is easily parsed to
XML-MAIDEN format [2] or to HTML format and next displayed via standard
CSS. The program is to continuum substitution of XML, HTML, CSS layers
for new CanonML layers.
> As an alternative to a brand-new service, one hack I have been
> thinking about from time to time is to get permission to use
> Google's XML interface to their search engine, then write an
> interface that maps between s-expressions and XML, so somebody
> could connect to my CGI application, submit Google searches in
> s-expression format, and get back RMI objects/references in
> s-expression format, and then browse the RMI objects remotely via
> my service. As a distributed application, for my own personal use,
> I could write an s-expression client that submitted a Google search
> via my s-expression interface, then browsed the resultset to
> organize it better, then finally presents the nicely re-organized
> index of search results as a tree of virtual Web pages for me to
> browse from a regular Web browser.
I have in mind something similar except i would not convert to xml
format and that i would use cnml expresssions as input. When working,
it would do in any search engine, currently i am researching on the
surface of google, Yahoo!, and MSN engines.
I asked Google representative for specific support of metadata on their
scholar optimized engine but they recomend to me PDF format only for
online data, therein i am trying to develop a new search engine service
can access to metadata otherwise would be lost.
> Do *any* of those LISP projects have a (HTTP-accessible) server I
> can play with, to see their various encodings of XML, to compare
> them?
Online search by SXML, DSSSL, GSXML, Latte, Scribe... LML, the HOP
project nayone cited here other day, and you can find useful
information about the s-expressions being used and lisp and scheme
sources to final html and xml docs togheter with apps and code for both
off and online conversions. DSSSL is a ISO standard. SXML approach is
very 'complete' including SSAX (Scheme) parsers, libraries, and
others...
There is too many information.
> Do you really mean modification (incompatible changes), or merely
> enhancements/additions?
Both. At Arc community you can find both people adding cosmetic changes
over a CL or Scheme basis and people going beyond.
> > 3) Documentation. XML was designed for documents, S-expr for data.
>
> But documents *are* (one kind of) data!
Yes, by document vs. data people mean mixed vs. pure data.
> S-expressions have already been used to represent lots of different
> kinds of data. Surely they can also represent documents.
Yes. You can also represent docs in stone. The point is that s-expr are
not optimal for documents, somewhat as XML is not optimal for data.
> > There are several documentation systems based in s-expr (e.g. Scribe),
> > but failed to be popular when compared with acceptance of HTML or TeX.
>
> Both HTML and TeX suck when it comes to expressing mathematics.
Yes, but people has found both TeX and HTML more confortable than
s-expr for documentation purposes during decades. Scribe is even
previous to SGML!
> Compare these two ways of expressing the same thing:
> (expt (arrayelement x 5) 2)
> x superscript 2 backspace subscript 5 endelement
> Can you see that s-expressions clearly show the nesting of
> mathematical notation, whereas TeX acts like a manual typewriter
> moving head up or down with no reference to what the mathematics is
> supposed to really mean?
> 2
> x
> 5
> Is that even possible to express in HTML?
In a tricky way? Yes. I use a cnml format next is converted to HTML at
_client_ for rendering. Using classes and storing the source in a title
or alt element, you can maintain semantics: title='(expt (arrayelement
x 5) 2)'
Of course, you cannot access to the information in a easy way and
information is not structured, therein tricky. At least i can offer
today more mathematical information is possible with TeX and MathML
approaches and information. Full approach would need of a XML browser
or a CanonML or LISP browser.
> By the way, way back in 1975 I wrote a crude text-layout program
> (MRPP3 a.k.a. POX, successor to something (MRPPP and MRPP2) I had
> written in 1969-70), which had overlays (composible pieces of
> picture which could then be combined in various geometric
> arrangements to make larger pictures), and macros (syntax vaguely
> like Algol/MacSyma when called, defined usually to build overlays
> out of pieces). Bill Gosper wrote a dandy set of macros for his own
> use, enabling him to use my program to lay out immense continued
> fractions and matrices and hypergeometric series etc., not as
> pretty font-wise as Knuth's carefully tuned Tex, but properly
> structured per the nested mathematical expressions.
>
> Later, using PSL (Portable Standard Lisp), I re-wrote the program
> (now MRPP4) to work directly from Lisp nested-lists, basically
> using the same internal representation as Tony Hearn's "Reduce",
> producing output in several formats (ASCII-art, and IBM CRTs
> attached to VM/CMS system, and Unix workstations using X),
> including a visual interactive structure editor where the cursor
> covered an entire sub-expression, shown as that part of the display
> highlighted, and could be zoomed in or out and panned up or down
> the current level of structure, and then a command could be
> executed on the current sub-expression as embedded in the larger
> expression to perform algebraic manipulations.
>
> MacSyma used a vaguely similar internal representation to Reduce, a
> bit more ugly in my opinion. But in any case, the basic idea is
> that internal Lisp structures were used to represent mathematical
> documents, and then of course PRINT could externalize such data and
> READ could get stuff back in, and MRPP4 could render the data
> structures in the usual mathematical-notation format. (MacSyma also
> had a math-format display mode, which it normally used for all
> output in the ordinary Read-MathEvaluate-Print loop. AFAIK MacSyma
> display output provided *only* ASCII-art mode, but I'm probably
> mistaken.)
Wow!
> Anyway, one application I'm thinking of writing is a port of MRPP4
> to CGI/CMUCL, whereby s-expressions from the client get
> internalized to Lisp structures and then displayed as
> MRPP4/MacSyma-style ASCII art, using <pre>...</pre> of course to
> make sure things line up in all browsers.
Interesting! I decided do not use ASCII art. I use basic CSS+HTML
rendering techniques i adapted from XML-Maiden project to HTML, working
minimally for 'modern' Gecko, trident, and Opera engines (> 95%
clients). Very old browsers can still access the math but displaying
the source code. I work stuff as [Y = [a / 2]] but techniques can be
easily adapted to (= Y (/ a 2)).
> Of course I'd also have
> an output mode for box-diagrams showing how the internal data is
> structured. The math-display output would work only for valid math
> structures, whereas the box-diagrams would work for all Lisp data.
Interesting again, i plan an automatic tree drawing and also an first
class typesetting engine without TeX metrics not conventions for a
future.
For instance [a = [b + c]] i.e. (= a (+ b c)). TeX does not correclty
structure the maths, then the engine simply generates a sequence of
tokens a = b + c and next recognizes the + as special binary operator
and the = as special relation operator, checks some built-in metric
tables and adds automatic 4/18 and 5/18 spacing around operators
respectively.
This is time-consumming, obligate to store the metric table and assumes
meaning about symbols, e.g. asumes that = is operator equals when could
be not. Presentation MathML correct this and can differentiate beteeen
<mi>=</mi> and <mo>=</mo>.
I had thought of someting as direct rendering of underliyng nested
structure [a = [b + c]] where each box [ ] receive extra space around
it. This way the b got more space around the = than around the +. It is
automatic, display represents the nested structure, is cheap and
do not need of metric tables or predefined symbols. What do you think?
> Indeed! With 100 proposed, I would expect to see live
> Web-accessible demos of at least twenty of them already.
> Do you know of any such?
Yes, i revised all of that in previous research. Several focus on some
subset as XSLT or XHTML. Other try to be alternative as data format
others focus on some specific point as non-hierarchies.
Most of them are accesible online and contain tutorials, sources...
Some of them are non-continued projects as Latte. Wikipedia works with
alternative to xhtml, YAML got popularity, last changes on LMNL were
presented in last Extreme markup conference (there is an online demo in
some place now i do not remember) Markdown is used in several blogs...
Please follows the links or Google a bit.
> SXML provides a representation for XML documents in the Scheme
> programming language -a kind of dialect of LISP-.
> Is that really true, presumably some specialized Scheme notation
> that is incompatible with Common Lisp?
I do not understand you, is true what?
> I reserved the sequence :: for the tags because is "never" used in
> real practice.
The :: notation is not more used switching to #, but this is not still
closed issue. The character is escaped when apearing.
> At one point you said that [...] is more legible than (...), or
> that's what you seemed to say.
More people said that, specially with ] begining a new line. I read
that people claiming square brackets as alternative to parentheses in
next Scheme. I read also several people claiming square brackets for
next Arc. Graham appears to like rounded ones.
Also many modern languages recently arised use [ ] for arrays and
lists. Logo also uses [ ]. On any case {} is characteristics of C and
TeX, and () is of LISP and SXML, therefore [] appears to be a good
option.
[1] http://okmij.org/ftp/Scheme/SXML-as-database.txt
[2] http://my.opera.com/White%20Lynx/blog/show.dml/256124
Juan R. wrote:
> I propose something like
>
> [#p This is [#b bold]]
>
> for
>
> <p>This is <b>bold</b></p>
I like it!
But a few points need to be addressed.
1. Attributes
Attributes are needed, both for compatibility with existing HTML/XML and
for the reasons expressed in the CanonML document. What do you propose?
[#div :id "one" :class "left red" This is the text.]
[#div @id "one" @class "left red" This is the text.]
[#div [@id one] [@class left red] This is the text.]
2. Whitespace
If <b>a</b> becomes [#b a], what about <b> a</b>?
Is [#a a] [#b b] equivalent to <a>a</a><b>b</b> or to <a>a</a> <b>b</b>?
And so on.
3. Namespaces
Intuitive solution?
[#fo:block Hello, world!]
All in all it looks good! Why don't you write it all down in a
semi-formal way and start an open source project to write an
implementation?
The implementation should translate between this representation and XML
(for compatibility) or better to and from SXML, as SXML is actually a
good internal representation of XML for Lisp programs.
Toby
Toby wrote:
> I like it!
> But a few points need to be addressed.
>
>
> 1. Attributes
>
> Attributes are needed, both for compatibility with existing HTML/XML and
> for the reasons expressed in the CanonML document. What do you propose?
>
> [#div :id "one" :class "left red" This is the text.]
> [#div @id "one" @class "left red" This is the text.]
> [#div [@id one] [@class left red] This is the text.]
We need both structure and unified data model.
Add also elegance to the goals. Something as :class "left red" or
@class "left red" is unelegant from a formal point of view because
visually it looks as 3 tokens separated by two spaces when really are
only two tokens :class and a string with a space.
I see two posibilities:
A S(cheme)XML like one
[#div [# [#id one] [#class left red]] This is the text.]
where attributes are just data but inside an anonimous list [# ]
A different where attributes are just data and for avoiding naming
conflicts are in an attribute namespace @
[#div [····@ one] [·······@ left red] This is the text.]
I think that find more interesting the second because the language
verifies the call-by-key design.
The Scheme model uses a call-by-position design, very usual in LISP
designs
(function 1stparameter 2ndparameter ...)
but avoided in SGML/XML/HTML low-level document processing.
>
> 2. Whitespace
>
> If <b>a</b> becomes [#b a], what about <b> a</b>?
As in TeX and LISP, multiple spaces are avoided, [#b a] and [#b a]
are the same structure (tree). As in TeX, wait a command adding space
but the unit is not 1/18 em but more precise. #sp appears to be a good
name, but do not worry about names because can change.
<b> a</b> becomes [#b [#sp] a]
> Is [#a a] [#b b] equivalent to <a>a</a><b>b</b> or to <a>a</a> <b>b</b>?
One of Microsoft XSLT enginneers summarized this in a clear way,
whitespace is one of perpetual nigtmares of XML. Graphically you can
see [#a a] [#b b] like
__|__ __|__
| | | |
#a a #b b
>From a data point of view, this is <a>a</a><b>b</b> because just two
nodes with content a and b.
However, note that MathML deals <a>a</a><b>b</b> and <a>a</a> <b>b</b>
as equivalent structures and most modern XML languages (except XHTML 2
because its HTML inheritance) avoid structures with anonimous text
nodes
<a>
|
|__ "a"
<>
|
|__ " "
<b>
|
|__ "b"
would be something like
[#a a] [# [#sp]] [#b b]
Trees to trees!
However, _any_ XML odd WS rule
<ul><li>a</li><li>b</li></ul>
(no spaces)
<ul> <li><span>a</span></li><li><span> b</span></li></ul>
(all spaces ignored)
<p> <span>a</span><span> b</span></p>
(all spaces ignored except two latter before the 'b' transformed into
one for rendering 'a b')
could be implemented in CanonML at a _macro_ level because backward
compatibility, simply it will be not done at the fundamental layer by
default because is all a mess.
Python WS rules could be also implemented at a _macro_ level!
[#python-code
code without brackets, just indentation here...
]
> 3. Namespaces
>
> Intuitive solution?
>
> [#fo:block Hello, world!]
Yes, except not sure if using prefixes or postfixes for namespaces
[#fo:block Hello, world!] or [#block:fo Hello, world!]?
It has been discovered that XML namespaced languages are very
unreadable but the current tendency is to full namespaces data: think
of html: mml: svg: fo: xsl:... I suspect unreadability is because the
prefix notation obligates you to read three or four tokens before
matching the tag you want, e.g. imagine you want to find the tag delta
on
<foo:alpha>...</foo:alpha>
<foo:beta>...</foo:beta>
...
<foo:alpha>...</foo:alpha>
<foo:alpha>...</foo:alpha>
<foo:delta>...</foo:delta>
<foo:alpha>...</foo:alpha>
<foo:beta>...</foo:beta>
...
and on
<alpha:foo>...</alpha:foo>
<beta:foo>...</beta:foo>
...
<alpha:foo>...</alpha:foo>
<alpha:foo>...</alpha:foo>
<delta:foo>...</delta:foo>
<alpha:foo>...</alpha:foo>
<beta:foo>...</beta:foo>
...
what is better?
Also multiple namespaces A:B:C are permitted. As in S(cheme)XML you can
use the URL directly because not XML limitations for tag names.
> All in all it looks good! Why don't you write it all down in a
> semi-formal way and start an open source project to write an
> implementation?
I am receiving feedback and discussing it off-line with a number of
specialists (except LISP ones who remain uninterested :). This project
changed a lot of since i began it.
For instance, initially i used [a #over 2] for formatting fractions.
This was an infix version of a prefix (over a 2) -if following a LISP
like syntax-. This is a call-by-position structure. You know that a is
the numerator because is the first argument for the "over" call. This
can be odd when processing!
I discovered this practice is going to be avoided in modern theory of
metalanguages [1]. Therein last Ecma XML (currently in draft) uses
calls-by-key at fundamental level (calls-by-key are good at macro
level, however) as ISO-12083 did for mathematics formatting.
Therefore, now i write [a #over 2] at editing/storing layer but this is
transformed to [#fract [#num a] [#den 2]] at the structural layer.
Now the project is formal and i wait to publish a paper on syntax and
basic data model for the beggining of next year. Desing of specific
modules (for text, for graphics, for science...) will begin next.
One obtains a better (consistent) structuration than LISP but less
parentheses -a LISP-like syntax needs of 325% more parentheses [2] for
typical scientific equations- and none extra ". Several features
proposed for Arc (as tree pointers) are already built-in. CanonML is so
easy to type like TeX and is more powerful than XML (recursive
metadata, better internationalization...).
This week :) version for CanonML is debating between
Version 1: the # is substituted by \ as in TeX.
[\para Next is a fraction [a \over 2]]
"\" is escaped like [\bksh] or similar, or maybe [\\]
Version 2: No special symbol for operators. Operators are written in
caps
[PARA Next is a fraction [a OVER 2]]
More terse still! Now caps needing escaping. LISP 'quote' appears to be
nice: i.e. [E ] means (prefix) operator E, whereas ['E ] means symbol
E.
What do you think?
CanonML LISP-2 (Kent Pitman would say LISP-6)
[LIST list] (list list)
[list list] '(list list)
[h FACT] ----
[m OVER w] ----
[FOO BAR] ----
Would last one be good for non-hierarchies? For instance
[A B c] [A d]
like counterpart for GODDAG <A/ <B/ c /B> d /A>
> The implementation should translate between this representation and XML
> (for compatibility)
Yes, this is on the target. For instance, a XSLT with XHTML encoded in
CanonML
[?xml [·········@ 1.0] [··········@ ISO-8859-1]]
[\stylesheet:xsl [·········@ 1.0] [···········@
http://www.w3.org/1999/XSL/Transform]
[\template:xsl [·······@ /]
[\html
[\body
[\h2 My CD Collection]
[\apply-templates:xsl]
]
]
]
[\template:xsl [·······@ cd]
[\p
[\apply-templates:xsl [········@ title]]
[\apply-templates:xsl [········@ artist]]
]
]
[\template:xsl [·······@ title]
Title: [\span [·······@ color:#ff0000]
[\xsl:value-of [········@ .]]]
[\br]
]
[\template:xsl ······@ artist]
Artist: [\span [·······@ color:#00ff00]
[\xsl:value-of [········@ .]]]
[\br]
]
]
Nice, concise, and more readable that XML syntax of XSLT!
The translation from XML to CanonML will be done via a XSLT. Now, i am
working in a CanonML to HTML conversor, including maths!
> or better to and from SXML, as SXML is actually a
> good internal representation of XML for Lisp programs.
The creator of SXML said me that find this project interesting but he
want to focus on a Scheme processing of XML; whereas this project
generalizes XML, for instance meta-metadata.
[1] Processing overload for deepdly nested structures.
[2] Even reduction from 17 parentheses to 4 for the same mathematical
encoding _without_ precedence rules or similar simply because a better
topology for the tree structure.
Juan R. wrote:
> CanonML is so easy to type like TeX and is more powerful than XML
You have me sold!
Here are some random thoughts.
> the # is substituted by \ as in TeX.
Great! I find [\em this] to be more readable than [#em this], because
of the shape of the symbol. Also \ is faster to type than # and people
will recognize it from TeX.
> It has been discovered that XML namespaced languages are very
> unreadable
...
> Also multiple namespaces A:B:C are permitted. As in S(cheme)XML you
> can use the URL directly because not XML limitations for tag names.
These are good points, but I personally still find prefix namespaces
more readable. Maybe it's because I'm accustomed to it, but
[\xsl:template [·@:match cd]
is easier to read than
[\template:xsl [·······@ cd]
I also don't understand why would anybody need multiple namespaces per
tag. Isn't one already too much? :)
> attributes are just data and for avoiding naming conflicts are in an
> attribute namespace @
Excellent idea!
This is compact, unified and readable:
[\div [·@:id one] [·@:class left red] This is the text.]
Byt the way, I still find postfix namespaces more cumbersome to read:
[\div [····@ one] [·······@ left red] This is the text.]
But maybe it's just force of habit.
> No special symbol for operators. Operators are written in caps
This I strongly object to. You would lose case sensitivity on tag
names; you would add strange things, where [CD] is matched by
[XSL:TEMPLATE [@:MATCH cd]
(notice the case of "cd")
More importantly, you would need to escape any uppercase text,
introducing tons of ['STRANGE SYNTAX] just to say SIMPLE THINGS.
Not good.
> <b> a</b> becomes [\b [\sp] a]
So you would discard all text nodes containing just whitespace, and also
strip whitespace from the beginning and end of the remaining text nodes?
What about inter-word whitespace? Would you collapse *any* whitespace
to a single horizontal space? As in 's/\s+/ /g' ?
It does make sense, but then [\em markup] usage would suffer.
> I write [a \over 2] at editing/storing layer but this is transformed
> to [\fract [\num a] [\den 2]] at the structural layer.
This requires the reader to know that \over becomes \num and \den.
I think it violates XML's independence from the application language and
therefore is bad. But see below for a possible solution!
> _any_ XML odd WS rule could be implemented in CanonML at a _macro_
> level because backward compatibility, simply it will be not done at
> the fundamental layer by default because is all a mess.
The idea of CanonML macros is great! I think it can be extended
further. I suggest using '[\' for structure, while '[#' for macros and
for other reader directives. Examples:
[\div [#markup Here, only [\em word-delimiting]
space is preserved, although collapsed. ]]
-> "Here, only /word-delimiting/ space is preserved, although collapsed."
[#markup [\div In the following code snippet, newlines/whitespace are
not collapsed, although whitespace is still stripped from
the beginning and end of the code snippet:
[#pre
(defun fact (n)
(if (zerop n) 1
(* n (fact (1- n)))))
]]]
-> "... of the code snippet: (defun fact (n)
(if (zerop n) 1
(* n (fact (1- n)))))"
[\b [#sp] a] <- this is the "<b> a</b>" example. [#sp] is not [\sp]!!!
But wait, there's more!
[#define [a \over b]
[\fract [\num a] [\den b]]]
[#define [\copyright]
[\p Copyright (C) 2006 Innovative Ideas, Inc.]]
[#import MathML] <- this is where all the positional stuff is #define'd
> I am receiving feedback and discussing it off-line with a number of
> specialists (except LISP ones who remain uninterested :)
Too bad :(
Have you read Paul Graham's article* about programming language
popularity? This project has great potential (web 3.0 indeed!)
I'd hate to see it die.
Do you have a mailing list yet?
Toby
* http://www.paulgraham.com/popular.html
Toby ha escrito:
> I also don't understand why would anybody need multiple namespaces per
> tag. Isn't one already too much? :)
Namespaces are an elegant way to avoid naming conflicts from different
languages, but cannot avoid naming conflicts inside the same language.
People is using attributes for that. For instance, <OM:OMS cd="arith1"
name="sum"/> denotes a symbol sum from arith1 from OM namespace.
In my opinion multiple namespaces could be an elegant way also to
modularization. For instance, OM:ARITH1:SUM appears to me more
interesting that [OM:OMS SUM [@:CD arith1]]. Nobody is obligated to
follow this way, it is an option I offer but i think that using name
attribute looks as odd to me as writting <tag name="emph"> instead
<emph>.
> > No special symbol for operators. Operators are written in caps
>
> This I strongly object to. You would lose case sensitivity on tag
> names;
Yes, this needs to be addressed and carefully discussed.
However, the mixture of cases on tags is usually considered a bad
practice in language design and this may be maintaind in mind.
Most of languages uses either all caps (HTML, OM...) or not (XHTML,
MathML...). Therefore, I am not sure at what extensions stuff as
<FontSize> would be 'permitted' on CanonML. Note that even B. Gates
changed the name from early MicroSoft to current Microsoft.
> you would add strange things, where [CD] is matched by
>
> [XSL:TEMPLATE [@:MATCH cd]
>
> (notice the case of "cd")
Hum! This is a problem of XSLT. In XSLT you write, match="cd" when you
are really matching <cd> not "cd", and you write "cd[@year='2005']" for
matching <cd year="2005">. Not just XPath is a new language (new
syntax, new parsers, new editors...) but that you may use different "
and ' for avoiding XML formedness errors.
If you choose \cd as notation for the tags, the XSLT would be [·······@
cd] not [·······@ \cd]. XSLT is that way, they invented a non-XML
string language for matchings, but that limitation is not forced in
CanonML.
An alternative to XSLT will be designed once basic language was ready.
It will use the same CanonML encoding for matchings. E.g. If you want
match structure [\cd [······@ 2005] ?] you would write
[\csl:target [\cd [······@ 2005] ?]]
with
[\CSL:TARGET [CD [@:YEAR 2005] ?]]
for the other syntax [CD [@:YEAR 2005] ?]
> More importantly, you would need to escape any uppercase text,
> introducing tons of ['STRANGE SYNTAX] just to say SIMPLE THINGS.
>
> Not good.
However, other people blames the tons of \ arising in complex
encodings. And they do not write on uppercase text (option is not
recommended by style guides) because even for abreviations they choose
small caps.
The principle of separation of presentation from content may be also
maintained in mind. Why would anyone write something in all caps,
because abreviation? because emphasis? Then it would use semantic tags
and leave to the style language renders correctly. The use of
presentational tricks to suggest semantic information is highly
disacouraged.
>
> > <b> a</b> becomes [\b [\sp] a]
>
> So you would discard all text nodes containing just whitespace, and also
> strip whitespace from the beginning and end of the remaining text nodes?
> What about inter-word whitespace? Would you collapse *any* whitespace
> to a single horizontal space? As in 's/\s+/ /g' ?
No single answer. Any problem or ambiguity in the XML input [1] will be
with us in the CanonML output when using an automated general
conversor. In some XML applications <foo>a</foo> and <foo> a</foo> are
the same, in others they are not. If not XML tool can solve this issue
[1] how could a conversion to CanonML representation solve it?
Fortunately, (pure) CanonML applications will be free from WS
nightmares and probably it would be best split application landscape
into two great zones: pure applications born in CanonML and conversions
from other languages as XML or TeX.
For instance, directly copying the XML of [1] on a CanonML format would
include all the WS ambiguities of the original XML format.
Directly copying the TeX source {\alpha \over 2} to CanonML does not
improve the syntatic ambiguity of the original code. But those are
problems of TeX and XML.
I think that it is not unreasonable to define next rules for
canonicalization of cnml docs
<sp><sp> --> <sp>
<[><sp> --> <[>
<sp><]> --> <]>
Therefore, [a b c], [ a b c] [a b c] all are defining the same
list. TeX ignores extra spaces in text mode and _any_ space in
mathematical mode.
Rest of WS rules could be implemented as modules over a default base.
This way, people could implement Python like indentation rules if they
desire. I personally prefer default bracketing and ignoring of
new-lines but...
>
> > I write [a \over 2] at editing/storing layer but this is transformed
> > to [\fract [\num a] [\den 2]] at the structural layer.
>
> This requires the reader to know that \over becomes \num and \den.
>
> I think it violates XML's independence from the application language and
> therefore is bad. But see below for a possible solution!
I do not understand you. It is as XSLT transformations, or TeX or LISP
macros: code generating code.
> The idea of CanonML macros is great! I think it can be extended
> further. I suggest using '[\' for structure, while '[#' for macros and
> for other reader directives. Examples:
>
> [\div [#markup Here, only [\em word-delimiting]
> space is preserved, although collapsed. ]]
>
> -> "Here, only /word-delimiting/ space is preserved, although collapsed."
>
A recent idea from the XML camp is to use # for character entitities.
Current XML: Ʃ
Proposal for XML: <#425>
Maybe we would leave #... for 'character entities', maybe not.
> [#markup [\div In the following code snippet, newlines/whitespace are
> not collapsed, although whitespace is still stripped from
> the beginning and end of the code snippet:
> [#pre
> (defun fact (n)
> (if (zerop n) 1
> (* n (fact (1- n)))))
> ]]]
>
> -> "... of the code snippet: (defun fact (n)
> (if (zerop n) 1
> (* n (fact (1- n)))))"
Interesting. Do not sure what would be the best way. I am managing
different posibilities including verbatim PIs.
> [\b [#sp] a] <- this is the "<b> a</b>" example. [#sp] is not [\sp]!!!
Sorry :]
> But wait, there's more!
>
>
> [#define [a \over b]
> [\fract [\num a] [\den b]]]
>
> [#define [\copyright]
> [\p Copyright (C) 2006 Innovative Ideas, Inc.]]
Yes, this was on the target when discussed the relationships between
\over and \frac. However, it would be noticed is not a definition in
the LISP sense (oriented) but a reciprocal binary relationship. I.e.
relationship is not --> as the define construct but <-->.
> Have you read Paul Graham's article* about programming language
> popularity?
Yes. Both agree and disagree. Part of his rationale does not apply
outside the PL field.
For instance, short names are a big win on programming languages but
are not in other languages. The tendency on markup languages is just
the inverse.
<p> (HTML) ---> <para> (Docbook) ---> <paragraph> (XML-MAIDEN, XAML,
CanonML...)
Of course, you can define shorthands according to your personal
preferences: p, para, par.
CanonML will include a generic function generating automatic shorthands
for descriptive names. For example:
[\shorthand integer] --> int
[\shorthand italic] --> it
[\shorthand equals] --> eq
[\shorthand sine] --> sin
[\shorthand logarithm] --> log
[\shorthand emphasis] --> emph
[\shorthand conditionals] --> cond
[\shorthand maximum] --> max
etc.
Note, one obtains common abbreviations for functions in several LISP
dialects in an automatic way!
> This project has great potential (web 3.0 indeed!)
> I'd hate to see it die.
Do not worry, there is enough people interested on this [2]. As Paul
said, this is the only strong attempt to one single language covering
multiple W3C specs.
> Do you have a mailing list yet?
No. I had thought on a more formal way. Publishing a formal paper
discussing the design with comparison with other approaches as TeX,
SGML, and S-expr languages for the very beginning of next year.
People would work over that basis.
[1] http://nothing-more.blogspot.com/2004/10/where-xml-goes-astray.html
[2]
http://canonical-chemistry.chemblogs.org/archives/2006/12/01/Chemistry-and-maths-online-CanonML
Juan R. ha escrito:
> In my opinion multiple namespaces could be an elegant way also to
> modularization. For instance, OM:ARITH1:SUM appears to me more
> interesting that [OM:OMS SUM [@:CD arith1]]. Nobody is obligated to
Would be [OM:SUM [@:CD arith1]]
> [\CSL:TARGET [CD [@:YEAR 2005] ?]]
would be [CSL:TARGET [CD [@:YEAR 2005] ?]]