Hi Dimitre,
Thanks for your ideas.. So I guess, we have to use
variables as they are in XSLT now, and do workarounds
like recursion etc. to simulate procedural kind of
tasks. Probably functional programming advantages far
out weigh the need felt for procedural features like
incrementing of variables..
Regards,
Mukul
--- Dimitre Novatchev <dnovatchev(_at_)yahoo(_dot_)com> wrote:
"Mukul Gandhi" <mukulw3(_at_)yahoo(_dot_)com> wrote in message
news:20030828014403(_dot_)37385(_dot_)qmail(_at_)web41104(_dot_)mail(_dot_)yahoo(_dot_)com(_dot_)(_dot_)(_dot_)
Hi Dimitre,
I am convinced that side effects are bad in a
programming language.
I didn't say that... Waht I said is that
uncontrolled side-effects are
dangerous. There are ways to control side effects
reliably (e.g. using a
Monad Type Class) and these have been incorporated
(supported at the
syntactic level) in some languages (e.g. the "do
notation" in Haskell).
For explanation of Monads see:
Tackling the awkward squad: monadic input/output,
concurrency, exceptions,
and foreign-language calls in Haskell, by
Simon-Peyton Jones at:
http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/
This is also possible to implement in XSLT (and I
have such an
implementation). Probably, in version 4 or 5 XSLT
might have such a
mechanism incorporated into the language. A
prerequisite for this is to make
functions first class objects (to treat them as any
other data type -- to
allow functions to be passed as parameters and
functions to be returned as
the result), which could happen in version 3 of
XSLT.
One could always control side-effects manually, but
this is tedious and
error-prone.
Thanks for the links for
information about this topic. I believe the
objective
of XSLT is to solve certain kind of problem(XML
data
transformations). The problem of generating serial
nos
comes frequently in real world situations.
This is not just one problem, but a class of
problems. You haven't specified
which is exactly your problem. Many of these "serial
number generation" or
"unique number generation" problems can be solved
with a two-pass solution.
All of them can be solved by using recursive
processing.
Would it
not be helpful(for transformations) if we can have
a
construct which can increment variables(not full
scale
-- but with limited features which can *aid* in
transformations)?
If we have a robust mechanism for controlling side
effects, then the answer
is yes.
Are we not justifying functional
nature of XSLT from a pure computer science view
point..
No, this is not "science for the science" but just
common sense derived on
very bad practical experience with side effects.
A programmer using an FP language must have
understanding about the issue of
side effects, otherwise this would be like an 8 yr
old driving a car.
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list