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

Re: The real harm is in functions with side effects (W

Subject: Re: The real harm is in functions with side effects (Was: Re: Using Extension Functions - Its Efficiency)
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Fri, 16 Jan 2004 00:44:19 -0800 (PST)
side effect haskell
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


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.