On Fri, 14 Dec 2001 16:24:14 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
