This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Functional programming in XSLT
- To: "Michael Kay" <mhkay at iclway dot co dot uk>
- Subject: Re: [xsl] Functional programming in XSLT
- From: Jeni Tennison <mail at jenitennison dot com>
- Date: Thu, 15 Mar 2001 17:19:43 +0000
- CC: xsl-list at lists dot mulberrytech dot com, "Dave Hartnoll" <themainman at 3b2 dot com>, "Steve Muench" <Steve dot Muench at oracle dot com>
- Organization: Jeni Tennison Consulting Ltd
- References: <000b01c0ad3b$cf4d4fc0$2d3a3c3e@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hi Mike,
> Secondly, I don't like treating multiple exsl:result's as a
> "recoverable error". I can't think of too many existing cases in
> XSLT 1.0 where people are going to write stylesheets that depend on
> errors being recovered by one processor, where they are going to
> have considerable difficulty fixing the error if another processor
> chooses not to recover from it.
>
> I still prefer having a static constraint on where <exsl:return> can
> appear, but if you can't live with that, have a strict rule that
> only one may be instantiated.
I'm just putting the finishing touches on a new version of EXSLT -
Functions that makes the changes that you suggested and Steve
supported, and I've come up against the question about whether to
specify that exsl:return actually terminates the function or not. I
thought I'd take a look to see how you'd done it in Saxon. I used the
following test:
<saxon:function name="my:func">
<xsl:if test="true()">
<saxon:return select="false()" />
</xsl:if>
<xsl:if test="true()">
<saxon:return select="true()" />
</xsl:if>
<xsl:message>Doesn't terminate</xsl:message>
</saxon:function>
This function meets the static constraints on saxon:return and Instant
Saxon 6.2 runs it without complaint. I was expecting it to return
false and to not receive a message (the documentation I have says:
"Instantiating a saxon:return element causes exit from the call of the
enclosing saxon:function."). But in fact the result of calling
my:func() is true (the value of the last saxon:return that's
instantiated) and the message comes up, so I guess this means that
saxon:return doesn't terminate the function.
Perhaps this is just a bug in version 6.2, but I was thinking: surely
it wouldn't matter if more than one exsl:return element is
instantiated if the function is terminated on the instantiation of the
exsl:return element. Rather than it being an error, we can just say it
never happens.
But perhaps it's difficult to implement something that terminates on
the instantiation of a particular instruction, given that this is
somewhat divergent from how instantiating instructions works in other
situations?
In that case, would it be easier to implement/understand if we said
that exsl:return cannot be instantiated more than once, but other
instructions can be instantiated after exsl:return?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list