[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: Can solve the N-queens - but can't count!
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 17 Jun 1999 11:38:45 +0200
xul to html
Scott Boag/CAM/Lotus <Scott_Boag/CAM/Lotus@xxxxxxxxx> wrote:
>The reasoning
[for being side-effects free]
>is so the templates can be processed as fragments, for
>applications like XML editors where an edit occurs and only part of the
>document needs to be updated.  There are already several features (params,
>modes, etc.) that make this hard, but we think it is still feasible.


There is also the problem that any template can refer to any part of the
input tree (counting, testing, etc.) using absolute paths. As you point out,
this is hard but still doable. I feel that preserving XSLT side effects free
is worthwhile, especially as this does not necessarily preclude ease of use.

>Though it is fun to do things like N-Queens in XSLT, it's not really the
>design center for the language.

I used this just as a benchmark for XSLT power. Again, it would have really
helped if the XSL WG had invested some time at the start of the process in
creating a representative set of transformation tasks. Then it would have
been easier to say "this is beyond the range of intended transformations".
Today, this range is a matter of personal interpretation. For example, is
SAXON's XSLT-to-Java compiler in this range? XUL to HTML? EDI to SQL? HTML
to indexed text?

The alternative is not to try to define such a range, and instead to try to
define a good generic tree transformation language. This seems to be what
the WG is doing, and quite well actually.

>  Once you add for and while loops and
>mutable variables, you almost might as well use JavaScript or perl or the
>like.  If we loose the ability for tools like editors to do fragment
>display, we have greatly diminished the uniqueness and viability of the
>language, in my opinion.


I absolutely agree with regard to mutable variables, but I beg to differ
with regard to loops. As I've shown, it is perfectly possible to define
loops as a shorthand syntax for tail recursion, without resorting to side
effects; in fact it is possible to do so by using XSLT to transform the loop
syntax into existing XSLT syntax (given a spare weekend I'll do that and
post the results).

We have the benefit of 40 years of computer languages design. I don't think
anyone would debate the fact that structured programming - nested blocks,
multi-branch if statements, and loops - has proven to be something which no
language can do without. This might be due to the way our brains are wired,
to the way people are taught computers, or to the phases of the moon - it
doesn't really matter, as long as it gets the work done. XSLT is actually
pretty OK in this respect, but it omits the loop construct. I've seen much,
much worse in languages focused on some abstract mathematical model (how
does dynamic multiple inheritance, inherent parallelism and distribution,
and no loops or nested if statements sound?).

Share & Enjoy,

    Oren Ben-Kiki


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.