Re: [RT] Managing Flow and Resources (plus Cocoon/Scheme update)

[Ovidiu Predescu <ov...@cup.hp.com>]

On Fri, 14 Dec 2001 16:24:14 +0100, Stefano Mazzocchi <st...@apache.org> 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.

[snip]

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

[snip]

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

[snip]

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

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 <ov...@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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

Re: [RT] Managing Flow and Resources (plus Cocoon/Scheme update)

[Stefano Mazzocchi <st...@apache.org>]

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.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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

Re: [RT] Managing Flow and Resources (plus Cocoon/Scheme update)

[Mikhail Fedotov <mi...@kittown.com>]

Hi!

> In fact, if you look at the semantics, XSLT is pure
>  functional
> language, admitely with no possibility of defining new
>  functions at runtime.

Check out
 http://sources.redhat.com/ml/xsl-list/2001-11/msg01096.html

Mikhail

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