Re: Re: Incrementing a 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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format