cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: [RT] Managing Flow and Resources (plus Cocoon/Scheme update)
Date Tue, 18 Dec 2001 02:19:59 GMT
On Fri, 14 Dec 2001 16:24:14 +0100, Stefano Mazzocchi <> wrote:

> Gosh, I love this thread...

Me too ;-)

> > > Yes, I had the taste of the power of continuations when I dived more
> > > into the paper you presented (and implemented myself a few scheme
> > > examples to get the feeling of it).
> > 
> > I do like the concept of continuation as well. It gives you a better way
> > of writing interactive apps. It's like in the early days of programming
> > where you had stuff like this:
> > 
> >    write "prompt >"
> >    read answer
> >    if answer is correct
> >      do it
> >    else
> >      redo
> I think we all agree then: continuations are the way to go.
> I think we all need to thank Ovidiu for bringing this on the table. :)

And I should thank Florin Mihaila, a friend of mine, for pointing me
to Christian Queinnec's paper ;-). Florin actually implemented such a
system in Java, but using the continuation passing style programming,
which is an explicit way of maintaining the continuations in a
language that doesn't support them. Unfortunately the system is not
free software, so we cannot take a look at it.


> Again XSLT is a perfect example: you have to know HTML syntax (and
> that's easy nowadays), but you have to grasp basic programming
> constructs (selection/choice, variables, queries, expansions, precise
> syntax) and then you have to understand hard-core programming concepts
> as (nested recursion, event driven programming, inheritance,
> multi-dimensionality).

In fact, if you look at the semantics, XSLT is pure functional
language, admitely with no possibility of defining new functions at
runtime. That's why I think lots of people are annoyed by it, the
extensive use of recursion and the lack of side effects (aka no
variable assignment), is something unusual to most programmers. The
language was visibly influenced by DSSSL, but the designers chose to
use a more "standard" syntax, to not scare people away ;-) But the
concepts are exactly the same.


> I couldn't find a way to teach the concept of apply-templates that could
> resonate with them, probably because the concept of explicit recursion
> is too far away from their mindsets (in fact, XSLT xsl:apply-templates
> is very close to Scheme call-with-current-continuation, if you think
> about it!)

I don't think this is the right analogy. xsl:apply-templates is more
like recursively invoking a set of functions. A continuation is just a
way to denote the remainder of a computation, which in languages like
Scheme is a first class object, e.g. it can be manipulated in the
language. In a language with gotos, you can imagine a program being
composed of a set of continuations, each one starting with the
instruction right after a goto label. When a goto is executed, the
program continues with the continuation represented by the goto label
being jumped to.

With xsl:apply-templates, you always put new templates (which are
really functions) on the call stack, but once you pop them from the
stack, there's no way to invoke the same template in exactly the same
context. In a language with continuations, in your template you can
store the continuation in a global variable. After you return from the
template, you can always make use of the stored continuation to go
back in exactly the same state where you were at the time you save the


> > > At the same time, for global site-mapping semantics, the XML syntax is
> > > still the way to go.
> > 
> > This is a big +1 for me. After seeing the way how Ovidiu's proposals in
> > the scatchpad area defines pipelines in a Scheme/Lisp syntax I strongly
> > propose to stay with what we have in the sitemap today. The introduction
> > of map:call elements into the sitemap and the proposals from Berin
> > to separate pipeline definitions from mapping show
> > IMO a clear way where to go.
> I tend to agree here: the use of XML for the sitemap seems to be a more
> friendly look for the underlying semantics.

Again, don't misunderstand what you see in the scratchpad area. The
Scheme definitions you see will not, I repeat, will not be visible to
the end user. The XML sitemap will be translated in the internal
format, no Scheme code will be ever seen by an end user.

The things which will be seen are going to be the XML sitemap, and the
flow language, which will not be Scheme, but a Javascript-like

I'm wondering however whether you guys, who are Cocoon developers, are
going to dig into the details of the Scheme code ;-) I would certainly
love to, because so far the code being added is relatively small,
albeit it makes use of some high-level Scheme concepts.

For example, right now the sitemap definition is done in 36 lines of
code, plus additional comments. It is defined in sitemap.scm, and an
example of it is in test.scm. The code doesn't do anything else other
than selecting the right pipeline using the same regexp matching as we
have today. I'm working on hooking up the real stuff, readers,
generators, transformers and serializers. After this, I'll write a
mapping from the XML syntax of the sitemap to the Scheme syntax. So
the number of lines of Scheme code will most likely increase, but not
very much.

Some initial benchmarks show that the Scheme based sitemap
implementation is about 50% faster that the currently compiled
version. I'll produce more figures as I hook up the real Cocoon
components on the pipeline.

Best regards,
Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message