"Francis Norton" <francis(_at_)redrice(_dot_)com> wrote in message
news:3E6D2F7A(_dot_)6070800(_at_)redrice(_dot_)com(_dot_)(_dot_)(_dot_)
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