Re: [xsl] Relying on the orser of excution is harmful (Was: Re: XSL Help!!)

[Dimitre Novatchev <dnovatchev@xxxxxxxxx>]

"Gunther Schadow" <gunther@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3DF0C44C.7030808@xxxxxxxxxxxxxxxxxxxxxxxxx
> Thanks for the reminder, Dimitre.
>

Hi Gunther,

> I suppose one way of making sure extension functions are called in
> a certain sequence would be to wrap them in xsl:variable/@select
> statements and then make sure the variable is used in the next
> call to an extension function that depends on the previous call.
> Right?

OK, this is very close to the semantics of the "bind" operator of a
Monad.

However, if you have two xsl:variables one following the other, that
each references your $gizmo, there could be problems -- you cannot say
which will access $gizmo first. If these references change some Java
variable (e.g. property of an object), then overrun is possible.

One must ensure that ***all*** uses of an object from the outer world
occur after it has been initialized/modified.

I find that this is most naturally done with continuation passing style
(CPS) programming.


> This works nicely with Java APIs that return the main
> object even for methods that could just as well return void (and
> unfortunately most of them do...)
>
> <xsl:variable xmlns:e="java:my.Gizmo"
>     name="gizmo" select="e:new()"/>
>
> <xsl:variable xmlns:e="java:my.Gizmo"
>     name="configured-gizmo" select="e:configure($gizmo, ...)"/>
>
> <xsl:variable xmlns:e="java:my.Gizmo"
>     name="energized-gizmo" select="e:energize($configured-gizmo,
...)"/>
>
> Do you have a tip what to do if the Gizmo API is written as
>
>     public void configure(...);
>
> instead of
>
>     public Gizmo configure(...);
>

When an action changes the world but does not return any value, it has
to be chained with other actions using the "then" Monadic operator.

One can implement a chain of "then-ned" actions by passing a list of
them to be executed sequentially, or again by CPS.

[skip]

>
> It is also courious that while XSLT retracts much of the control
> flow implications of a sequence of nodes, it still requires a
> variable node to occur before that variable is referenced. It's
> not unreasonable to require that for both readability and simple
> processing reasons, but it might convey the wrong impression to
> the casual XSLT programmer.

I guess that this was a way to prevent circular dependencies.

>
> regards,
> -Gunther




=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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