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

["Kurt Cagle" <kurt@xxxxxxxxxxxxx>]

Dmitri,

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
it.

-- 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