This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
No side effects holy cow. ( Re: process order (still...) )
- To: xsl-list at mulberrytech dot com
- Subject: No side effects holy cow. ( Re: process order (still...) )
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Thu, 13 Apr 2000 10:52:14 -0700
- Organization: The Qub Group
- References: <200004130654.AAA46010@skew.org> <200004130852.JAA19604@nag.co.uk>
- Reply-To: xsl-list at mulberrytech dot com
----- Original Message -----
From: David Carlisle
> > Another why... Why would the order in which processing occurs not be the
> > order in which things get added to the result tree?
>
> Because when I buy my 1024 processor parallel processing machine
> I want to pass 1023 sibling nodes to all get processed at the same time
> and returned whenever each process finishes, then the remaining
> processor slots the returned subtrees into the final result tree in the
> correct place, as they come up. So the final tree has the `correct'
> order but the actuall processing hapened on each node whenever it
> happened. Allowing this is the main reason for not allowing template
> processing to have side effects, so disallowing it again in the text of
> the rec seems, er, strange.
I think this is the only reason behind 'no side effects' holy cow ?
I'l be happy to get any other reason of this limitation which
causes significant ( preformance ) problems to almost everyone
who tries to use XSLT in production 'outside' of XSLTs real
problem domain - ( I mean rendering of relatively small standalone
documents. That's what XSLT does well and almost clean. ).
What I can not understand is:
1. Is it reasonable to utilize 1024 processors to process a small
document?
2. If document is large - it'l eat the entire memory ( XSLT lacks streaming),
so the problem will be not to find extra processors, but to find some more
memory.
Are benefits ( mythical ) worth limitations ( real ) ?
Rgds. Paul.
PS.
Well... "No side effects" sounds very cool ( it is a good thing to
use wording like this when talking to management. The word
"shorthand" is also helpful, because it sounds much better
than "hack" ).
On another hand, when I'm explaining core principles of
XSLT to some novice *developer* , I'm using another wording.
I'm usualy saying : "because people who created XSLT are LISP
developers, they decided you can live without assignable variables,
that means to accumulate a string of N spaces, you should write
some code like this ... but you can not do it with something like
for ( i = "....).
I found reaction to this sentence to be more interesting than
reaction to the sentence "XSLT is side-effect free". The
"XSLT is side-effect free" form is usualy ignored by novice
developer.
By the way - another XSLT holy cow is xmlish notation.
"To save parser footprint". Anyway XSLT implementation has
to implement XPath parser, so savings are mythincal, but
extra-verbosity problems are real.
I think the same happens with "no side-effects" holy cow.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list