"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