i do agree that functional aspects of XSLT are
important. in fact, i was enlightened by Dimitre's
article at http://fxsl.sourceforge.net , where he
explained how XSLT can be equated with a functional
programming paradigm.. as Dimitre has explained , if
we imagine the XSLT templates as functions and treat
functions as higher-order we can produce very
effective techniques in the context of handling XML ..
if *only* variable increment is allowed in XSLT , to
how much extend would it introduce side effect can be
debated .. i guess, variale scoping will be a big
problem if variables are allowed to increment ..
i guess XSLT was invented to solve XML transformation
problem .. since XML is like a tree structure , so a
language to transform XML should be recursive and
functional ..! if somebody wants a imperative
programming style to handle XML , they can use DOM!
Regards,
Mukul
--- Wendell Piez <wapiez(_at_)mulberrytech(_dot_)com> wrote:
Mukul,
I'm also curious as to why this restriction is
imposed on XSLT, and never
fail to listen with interest to cogent explanations
of the theory behind
functional, "side-effect-free" programming.
However, otherwise I disagree. I like XSLT's
functional aspects, and am
greatly relieved not to have to pay attention to the
kinds of things that
more procedural languages burden the programmer
with. In other words, I do
not believe that this design decision represents a
net loss, or that XSLT
would be "really easy" if it allowed more side
effects: on the contrary,
I'm thankful that I can only imagine what XSLT would
be like if it were
more procedural.
After all, if you like that kind of programming
there are plenty of tools
available. People used to write markup transforms in
Perl, and it's still
very useful if you know what you're doing.
I think experience on this list also shows that many
times, neither an
incrementable variable nor recursion is really
necessary. (And note that on
the list we see the hard cases, and never hear about
all the things that
are easy.) Just as often, when the "problem" of
variable scoping comes up,
a programmer who is not familiar with the XSLT
processing model is jumping
to conclusions about how something needs to be done.
XSLT lets the
programmer concentrate on the "what", leaving most
details of "how" to the
engine. For whatever reason, some programmers don't
understand this or
don't like it, and insist on thinking too hard.
(Admittedly there's a
blurry line there. But note also that recursion and
such sophisticated
techniques come up on the list more often to handle
problems that XSLT
wasn't designed to deal with, like string munging,
than they do just to get
around the restrictions on variables.)
Just $0.02 from me. Interesting question.
Cheers,
Wendell
At 12:10 PM 6/27/2003, Mukul wrote:
We all know that XSLT does not allow
incrementing a
variable after declaring it. Myself and many of us
fell that it a major handicap in writing programs
easily in XSLT. To simulate the variables we have
to
use recursion and many sophisticated techniques. If
there is a feature of full scale variables in XSLT,
it
would make programming really easy. I am curious
why
this restriction is imposed in XSLT specification.
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc.
http://www.mulberrytech.com
17 West Jefferson Street Direct
Phone: 301/315-9635
Suite 207
Phone: 301/315-9631
Rockville, MD 20850
Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing
in SGML and XML
======================================================================
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list