[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] The real harm is in functions with side effects (Was: Re: Using Extension Functions - Its Efficiency)

Subject: Re: [xsl] The real harm is in functions with side effects (Was: Re: Using Extension Functions - Its Efficiency)
From: "Kurt Cagle" <kurt@xxxxxxxxxxxxx>
Date: Mon, 19 Jan 2004 01:22:21 -0800


I'm somewhat familiar with monads in Haskell; I actually had a chance last
year to delve into Haskell in preparation for a class that I didn't end up
taking after all (long story), but the notion of the monads makes a great
deal of sense. In essence, you are creating an algebra of functional
compositions to effect type constructors, as I understand the theory.

This bias of course is not completely unheard of on the imperative side. It
took me a long time to really understand why Kernighan and Ritchie did not
include i/o as a core functionality of the C language (ditto Pascal) and it
was really only with the fact that K&R understood the implicit problems with
side-effect-oriented languages but didn't yet have a foundation upon which
to formalize that relationship (as C preceded Haskell by several years, if
memory serves).

Perhaps the question that should be raised at this stage is whether in fact
there is a way to introduce monadic characteristics into XSLT2 at this late
date. I'm currenly working on a publishing system that is HEAVILY XSLT2
based, and struggling to keep my programmers on the straight and narrow wrt
side-effect oriented language. Could you point me to the direction of your
monographs on monads in XSLT2? I remember skimming it once, but I was heads
down in SVG code at the time and hadn't really taken the time to understand

-- Kurt

----- Original Message ----- 
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, January 16, 2004 12:44 AM
Subject: Re: [xsl] The real harm is in functions with side effects (Was: Re:
Using Extension Functions - Its Efficiency)

> Hi Kutrt,
> > Dmitri,
> >
> > We've talked on this issue before, and in the main I agree with you
> about
> > the issue of side effects.
> Yes, we agree on this issue and have essentially the same understanding
> about it.
> > This holds true in certain contexts especially
> > (the use of an imperative variable as an incrementer, for instance,
> > something that isn't as big of an issue with XSLT2 and sequences),
> The problem is not with XSLT or XSLT2 or with any functional language. The
> problem is that once you allow external functions, you cannot have any
> guarantees about their being side-effects free.
> So, the side effect happens within the external environment of the
> extension function and nothing can prevent it.
> An example is storing and updating (state) data outside of XSLT.
> The simplest and shortest example can be given with the use of the
> date:time() EXSLT extension function.
> In this case the programmer doesn't have to store and update the time --
> this is done for them automatically :o) :((
> Take this code:
> <xsl:stylesheet version="1.0"
>  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>  xmlns:dt="http://exslt.org/dates-and-times"
>  exclude-result-prefixes="dt"
>  >
>   <xsl:variable name="vT1" select="dt:time()"/>
>   <xsl:variable name="vT2" select="dt:time()"/>
>   <xsl:template match="/">
>     <xsl:value-of select="$vT2"/>
>     <xsl:for-each select="document('')//node()
>                          | document('')//@*
>                          | document('')//namespace::*">
>       <xsl:for-each select="document('')//node()
>                      | document('')//@*
>                      | document'')//namespace::*">
>         <xsl:value-of select="concat('&#xA;', position())"/>
>       </xsl:for-each>
>     </xsl:for-each>
>     <xsl:value-of select="$vT1"/>
>   </xsl:template>
> </xsl:stylesheet>
> Any assumptions that $vT2 >= $vT1 are wrong.
> In fact, when run with XalanJ 2.4.1 the result is:
>    09:11:50+01:00+01:00
>    [noise output]
>    09:11:51+01:00+01:00
> > and I
> > know that I work hard to educate my programmers about the dangers of
> > dealing
> > with side-effect systems. The problem that comes with XSLT2 is the fact
> > that
> > any access to a web service is implicitly a side-effect - the same call
> > with
> > the same parameters to the same web service will potentially return
> > different values and moreover potentially change the state of the called
> > service. Ditto the notion of <xsl:document-result>  with a packet of
> > information being sent to a web service.
> >
> > In other words, a side-effect free environment can only realistically be
> > maintained if the system itself is completely closed, yet most of the
> > interesting uses of XSLT only emerge when you open up the system a
> > bit ...
> A side-effect free environment is completely useless, because it cannot
> print (a side-effect operation!) any processing results.
> We have to live with side-effects and we actually can use side-effects in
> a controlled manner.
> Unfortunately, some functional languages (XSLT included) lack a built-in
> support for controlling side-effects.
> Haskell has the notion of a Monad class built-into the language and any
> programmer simply uses the IO (or any other suitable type) Monad, when
> this is necessary.
> I have my implementation of a Monad class - like support in XSLT and it
> allows functions with side-effects to be used in a safe and controlled
> manner.
> > however, I liken this to a novice trying to play jazz vs. a master jazz
> > musician -- the master will break the rules all the time, but only
> > because
> > he knows exactly why those rules exist in the first place and he weighs
> > the
> > risk of breaking them as the cost of achieving art.
> Actually, there is no risk -- the master knows and follows *additional
> rules* (Monads) that eliminate the risk completely. The master is a master
> because he knows something in addition to the rules used by the novices.
> > The novice breaks
> > them
> > out of ignorance, and just creates bad music, but it is the only way
> that
> > the novice will learn what those rules are in the first place.
> Fortunately, false melody can be felt immediately.
> However, in the case of programming everything may seem OK untill suddenly
> (e.g. with the use of another XSLT processor or a new version of the same
> XSLT processor) some completely surprizing results start to appear and it
> is impossible for the novice to understand and explain them.
> Dimitre Novatchev.
> FXSL developer
> http://fxsl.sourceforge.net/ -- the home of FXSL
> Resume: http://fxsl.sf.net/DNovatchev/Resume/Res.html
> __________________________________
> Do you Yahoo!?
> Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
> http://hotjobs.sweepstakes.yahoo.com/signingbonus
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread