[xsl] Re: Re: A proposal:xsl:result-document asynchronous attribute

Subject: [xsl] Re: Re: A proposal:xsl:result-document asynchronous attribute
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Tue, 11 Mar 2003 06:47:26 +0100
"Francis Norton" <francis@xxxxxxxxxxx> wrote in message
news:3E6D2F7A.6070800@xxxxxxxxxxxxxx
> Hi Dimitre,
>
> Dimitre Novatchev wrote:
>
> >Not in the case of a functional language  -- distinguishing between a
side
> >effects - free function and one that has side effects -- here this is a
> >matter of sanity.
> >
> >
> I agree that there would have to be a clear distinction, and I have to
> admit I have no idea how difficult this would or wouldn't be to
> implement. (I should also have used a less adventurous comaprison, since
> I triggered at least one recipient's rude-things filter)
>
> >Just to say that a function has side effects is not sufficient. There
must
> >be good mechanisms that support the use of functions with side effects,
> >otherwise the result of evaluation will be unpredictable.
> >
> >This is where the Monad implementation *is necessary*.
> >
> >It is possible to implement (something like) a general Monad in XSLT if
> >there are higher order functions and at least some kind of primitive
> >controlled lazy evaluation.
> >
> >Such an implementation has been produced using FXSL. It provides a
reliable
> >way of dealing with functions with side effects.
> >
> Ah - time for me to spend some time with FXSL, perhaps - I think I
> understand what Monads do in Haskell but never really had that "aha"
> moment - maybe seeing what you've done in a language I understand better
> will help.

As I said, the monadic implementation is not yet published, but in case
you'd like to play with it -- just let me know. I would highly appreciate
any betatester feedback and further suggestions.

>
> >While this sounds like a justified remark, it remains simply wishful
> >thinking if proper mechanisms to ensure reliable and predictable use of
> >functions with side effects are not in place.
> >
> Yes, I'd like to see it done properly. Though I have a feeling that
> getting it done properly will involve a major culture-transplant to non
> Haskell-heads such as myself.

I think it shouldn't be difficult to use.

Understanding is a completely different matter. Monads in XSLT will seem a
little bit strange. As I said in my previous message, this implements
"something like Monad" -- the reason is that XSLT does not have higher order
functions and strong type system, therefore it will be impossible to prove
the three monad laws for an XSLT implementation.

>
> >It is highly unlikely that XSLT 2.0 will offer such a mechanism, as it
lacks
> >standard support for higher-order functions.
> >
> >For the time being such support will be provided by the FXSL monadic
> >implementation.
> >
> >Before publishing the initial implementation I'm trying to collect a
number
> >of good-use examples, like maintaining state, update-in-place Arrays, IO
> >from external files, synchronous exceptions.
> >
> >I would greatly appreciate any other suggestions of possible use of a
> >monadic implementation from interested users.
> >
> timestamp, randomNumber and interaction with unsafe, non-idempotent
> web-services would be my favourite "unclean" features.

Thanks for these suggestions -- the first two are straightforward. I'm not
sure how a time-out will benefit from a monadic implementation though. This
is why I mentioned *synchronous* exceptions, asynchronous ones, like the
expiration of a timer, seem much more complex to handle.


Also, be prepared that a monadic implementation without a standard syntactic
sugar support from the language may seem not too nice.


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