cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Managing Flow and Resources (plus Cocoon/Scheme update)
Date Tue, 18 Dec 2001 15:48:13 GMT
Ovidiu Predescu wrote:
> > 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
> continuation!

All good points. I admit my analogy wasn't well thought out. Please
ignore it.

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

Great, this should remove lots of the syntax-friction some perceived so
far.

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

Good, this is what I wanted as well.
 
> I'm wondering however whether you guys, who are Cocoon developers, are
> going to dig into the details of the Scheme code ;-)

To be honest, that doesn't make me smile at all: I'd be afraid of having
such a vital part of Cocoon done in a language that is not appreciated
by the vast majority of the dev team.

I'm not saying that I reject the notion of sperimenting new ideas, but
it must be understood that if these new ideas (however powerful) don't
build roots into the dev community, they will likely be ignored and
abandoned. Or, even worse, create forking frictions or slow project
evolution down.

Again, being all this done into a scratchpad, it's not a problem right
now, but it might be if we decide to move in that direction so it must
be taken into consideration.

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

Well, the same can be said with the huge sitemap-generating stylesheet.
 
> 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.

I'm not scared by lack of visibility and readability. I'm scared by lack
of familiarity: say I want to add something to that code, it might be
just 40 lines and you could add the thing in 2 lines, but what if I
don't know what to do and have no time to study? some might get the itch
to rewrite the thing in java just because that makes them more
confortable (just like people proposed to rewrite the sitemap engine
interpreted to avoid messing up with XSLT+Java which is admittedly a
deadly mix).

On the other hand, instead of adding something into 10000 (ten thousand)
lines of java code for the interpreted sitemap, or into 3000 (three
thousand) lines of XSLT+Java code into a single file, it might be easier
to learn a little scheme and write the addition into 40 lines of Scheme
code.

But again, it's too early to tell: we have to judge the results, not the
assumptions.
 
> 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.

Those are good figures to start, but again, let's wait at the final
results to judge and let's support Ovidiu's innovations as much as we
can.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message