Re: Future of LISP. Alternative to XML. Web 3.0?

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).

.

Relevant Pages

  • Re: Do people dislike parentheses or the conceptual mismatch with trees?
    ... The more I have to wonder _why_ XML was ever even born let alone got so ... Because it wasn't Lisp. ... and s-expressions and were able to appreciate the benefits that would come ... version of HTML. ...
    (comp.lang.lisp)
  • Re: Validate S-expression against a DTD or equivalent?
    ... > of an ordinary Lisp S-expression. ... > some XML into equivalent Lisp. ... HTML" and built myself a couple of macros and support functions. ... where the macro made sure that it only had "Correct ...
    (comp.lang.lisp)
  • Re: Future of LISP. Alternative to XML. Web 3.0?
    ... I'm learning lisp from a few weeks I thought the same ... And you could say that the dtd declaration at the beginning of an xml ... The dtd are eliminated in Web 2.0 by Schemas, are just another XML ... HTML is not Web 2.0. ...
    (comp.lang.lisp)
  • Re: Future of LISP. Alternative to XML. Web 3.0?
    ... using s-expressions instead of XML, nobody is going to use it, ... because it's cheaper to keep the existing XML software and continue ... XML-MAIDEN format or to HTML format and next displayed via standard ... or a CanonML or LISP browser. ...
    (comp.lang.lisp)
  • Future of LISP. Alternative to XML. Web 3.0?
    ... i was newbie and i promoted XML as fascinating future ... There is not new LISP since many time, and projects as that of Arc ... But that LISP would be at the server (instead XSLT), ... Would a ISO standard for an alternative to XML save all of us? ...
    (comp.lang.lisp)