[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Incrementing a Global variable

Subject: Re: Re: Incrementing a Global variable
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Thu, 28 Aug 2003 06:43:36 +0200
haskell global variable
"Mukul Gandhi" <mukulw3@xxxxxxxxx> wrote in message
news:20030828014403.37385.qmail@xxxxxxxxxxxxxxxxxxxxxxxxxx
> 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.