[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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 |
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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Can solve the N-queens - but ca, david . rosenborg | Thread | Re: Can solve the N-queens - but ca, Oren Ben-Kiki |
RE: Can solve the N-queens - but ca, david . rosenborg | Date | Re: Can solve the N-queens - but ca, James Clark |
Month |