Re: Can solve the N-queens - but can't count!

James Clark <jjc@xxxxxxxxxx> wrote:
>I wouldn't assesss the feasibility of such
[incremental]
>implementations on the basis
>of whether it's possible to create cases that such implementations will
>handle very inefficiently: I don't think it's possible to create a
>transformation language that does what XSLT needs to be able to do and
>yet does not permit such cases.

Agreed.

>I would instead assess the feasibility
>on the basis of how well the implementation does for typical
>stylesheets, how well it does on average.  This is very hard to
>quantify.

This is a fine way of assesing implementations, but it is not a good way to
assess proposed language features.

>There are lots of things in XSLT today that probably make an
>incremental implementation harder: xsl:for-each, modes, named templates,
>parameters, local variables, absolute location paths, upwards and
>sideways axes (ie axes other than descendants and children), result tree
>fragment values for parameters and variables.  Making a judgement about
>where to draw the line is hard.  I'll freely admit that I'm worried
>about whether XSLT has drawn the line in the right place, but my worry
>is not that we've left things out but rather that we've gone too far and
>put too much in.  However I have a hard time thinking of things that I
>would be willing to see left out of the current WD.


Once we've given up on XSLT as a language which can be implemented purely
"incrementally", I don't see the point in drawing the line at all. Once such
a line is breached, it becomes irrelevant. Using it as a criterion hampers
the stylesheet writers and doesn't gain anything for the implementers.
Instead, I'd rather focus the effort on protecting the remaining lines
without hampering the stylesheet writers - for example, how to express side
effects free loops.

The usual criteria still remain, of course - the usual tradeoff between
language complexity and power, usefulness for "real world" applications,
ease of implementation, etc. I think in these respects loops and the
matching on result tree fragments feature are no worse then, say, modes and
some of the more esoteric axes.

Share & Enjoy,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list