Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

something new: XQVM

9 views
Skip to first unread message

Tom Lord

unread,
Oct 5, 2007, 1:51:28 AM10/5/07
to
I've implemented a new programming language,
dubbed "XQVM". It is not quite Scheme, but it may
be of interest to Schemers because of the ways
it resembles Scheme.

There is a web site for the new language:

http://www.dasht-exp-1a.com/first-light/index.html

That page contains some commercial content but
all of the materials referred to here and there
are available free of charge, with open source
licensing.

How to explain XQVM to Schemers?.....

Suppose that we want to build a lisp, but
decide not to use cons pairs and symbols
and so forth. Rather, we'll use XML objects
(aka DOM objects).

Using XML instead of cons pairs means
that we can no longer build circular structures
or have other kinds of structure sharing. In
other ways, though, XML bears a lot of resemblence
to S-expressions (as is well known).

It is not hard to imagine writing Lisp-like
or Scheme-like "eval" rules that operate on
XML instead of S-expressions. This is,
in part, exactly what XQVM does. Thus,
XQVM is a very "lisp-like" language.

XQVM's evaluation rule defines a tiny core
language. There is but one construct in this
language. That construct allows a programmer
to combine an arbitrary side effect with an
arbitrary "single step rule". The job of the "single step
rule" is to construct the continuation to be
invoked after the currently requested side effects
are performed. Thus, core XQVM is similar to
an explicit continuation passing dialect of Scheme
or, perhaps more descriptively, core XQVM is a
very simple Actor language.

XQVM uses the language XQuery as a "sub language".
XQVM does not define an ordinary list of
"primitive operations" the way that most language
definitions do. Instead, every XQuery source
text doubles as the name of an XQVM primitive.
The semantics of the primitive are implied by the
semantics of the XQuery program that is its name.

It's a strange, powerful thing.

Please, enjoy.

-t

Tom Lord

unread,
Oct 5, 2007, 11:11:15 PM10/5/07
to
Wow. Talk about yr trees falling in forests....

Shit I thought people would go nuts over that.

-t

Nils M Holm

unread,
Oct 6, 2007, 2:05:37 AM10/6/07
to
Tom Lord <lo...@emf.net> wrote:
> Wow. Talk about yr trees falling in forests....
>
> Shit I thought people would go nuts over that.

They possibly would, if XML tags would match as nicely as parentheses.

Nils

--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/

Tom Lord

unread,
Oct 6, 2007, 3:14:13 AM10/6/07
to
On Oct 5, 11:05 pm, Nils M Holm <before-2007-10...@online.de> wrote:

> Tom Lord <l...@emf.net> wrote:
> > Wow. Talk about yr trees falling in forests....
>
> > Shit I thought people would go nuts over that.
>
> They possibly would, if XML tags would match as nicely as parentheses.
>


Isn't that mostly a problem with editors and pretty
printers?

-t

namekuseijin

unread,
Oct 6, 2007, 11:13:29 AM10/6/07
to

seemingly not. BTW, I don't think literal stuff in CDATA will ever
get popular.

Tom Lord

unread,
Oct 6, 2007, 5:13:09 PM10/6/07
to
I don't understand these criticisms
of the syntax of "core XQVM". They
seem to miss two very important points:


1. Core XQVM makes it easy to invent
entirely new syntactic abstractions.
As the intro page explains, that is the
main way to program XQVM. So if you
don't like the core language syntax,
just write a quick library to implement
a syntax you do like, and be done with it.

2. The core XQVM syntax has the extremely
pragmatic virtue that parsers for it come
"for free" in many interesting environments.
If your environment has an XQuery implementation,
an XML parser, and a good DOM model, you've
already got almost all of an implementation of
core XQVM. If the core syntax were different,
the core would be much harder to implement.


-t

Nils M Holm

unread,
Oct 7, 2007, 2:52:08 AM10/7/07
to

Pretty-printing may not be that hard, but for editing XML you need
an editor that understands XML at least at the lexical level. To
match parens in an S-expression, an editor has to count parens and
that's it. To match tags, you have to know a bit about the structure
of a tag: at least that it begins with <name.*, that <name.*/> does not
count, that </name.* matches <name.*, and that tags must match in pairs.
In other words, XML syntax is (IMO) quite baroque and very hard to edit
without a tool that is specialized in it.

Can you use syntactic abstraction in XQVM to get rid of that ugly
XML syntax altogether? If so, I would suggest to include code to
do so in the distribution and tell people about it at the beginning
of the README and the web page. This may get them interested.

David Rush

unread,
Oct 7, 2007, 3:51:38 AM10/7/07
to
On Oct 5, 6:51 am, Tom Lord <l...@emf.net> wrote:
> I've implemented a new programming language,
> dubbed "XQVM".
...

> XQVM's evaluation rule defines a tiny core
> language. There is but one construct in this
> language. That construct allows a programmer
> to combine an arbitrary side effect with an
> arbitrary "single step rule". The job of the "single step
> rule" is to construct the continuation to be
> invoked after the currently requested side effects
> are performed. Thus, core XQVM is similar to
> an explicit continuation passing dialect of Scheme
> or, perhaps more descriptively, core XQVM is a
> very simple Actor language.
...

> It's a strange, powerful thing.

It actually sounds rather a lot like a different kind of an approach
to an XSL Transformation language. And that is no bad thing, although
it is probably too late to develop any significant mind-share. I will
give it a look, although I have no real application right now.

david rush
--
http://cyber-rush.org/drr/scheme <- a fairly messy constructionn^Wweb-
site

Tom Lord

unread,
Oct 7, 2007, 4:11:48 AM10/7/07
to
On Oct 6, 11:52 pm, Nils M Holm <before-2007-10...@online.de> wrote:

> Can you use syntactic abstraction in XQVM to get rid of that ugly
> XML syntax altogether?


Sure. I would advise, instead, working on editors that
work on a DOM representation but don't require users
to literally type out XML syntax. But, sure, one could
make a completely non-xml syntax pretty easily (I would
guesstimate -- a bit less than 1K LOC).


> If so, I would suggest to include code to
> do so in the distribution and tell people about it at the beginning
> of the README and the web page. This may get them interested.

Someone who would be swayed from disinterest to interest
on that basis alone probably would be someone who really
doesn't understand the beauty of the technology -- so
such persons are not an audience I am much interested in
right now.

-t

Tom Lord

unread,
Oct 7, 2007, 4:19:26 AM10/7/07
to
On Oct 7, 12:51 am, David Rush <kumoy...@gmail.com> wrote:

> It actually sounds rather a lot like a different kind of an approach
> to an XSL Transformation language. And that is no bad thing, although
> it is probably too late to develop any significant mind-share. I will
> give it a look, although I have no real application right now.
>

No, not really.

Like XSLT you can use XQVM to do simple XML->XML transforms, sure.

But, XQVM brings to the table: relational algebra functionality
from XQuery, an ACID model of persistence, from the database back
end, a monadic model of side effects, higher-order procedures,
a process model, a fully reflective programming environment, and
a capacity for fully general syntactic abstraction (right down
to the lexical level, if needed). It's apparently going to take
more than 48 hours for this to sink into the theory community and
the compiler theory but XQVM is also an application in which many of
the best results of the past decade or two from type theory and
functional language implementation can shine, amazingly. People
today trade in appliances for things like network attached storage.
In a few years, there will be appliances for something closely related
to XQVM.

So, no, it's a lot more than a fancy XSLT.

-t

0 new messages