This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: [exsl] Naming exsl:return/exsl:result (Was: Re: Functional programming in XSLT)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [exsl] Naming exsl:return/exsl:result (Was: Re: [xsl] Functional programming in XSLT)
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Mon, 19 Mar 2001 21:52:29 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> Colin Muller wrote:
> > Is it doing something or being something? Is it to be viewed as an
> > instruction to the processor to perform a return, or as a statement
> > that at this point we are seeing some value? If that decision is
> > impossible or the answer ambiguous, ummm ... avoid the issue:
> > "exsl:return-value" could be read as imperative by those who want
> > imperative and as nominal by those who want nominal :-)
>
> Dave Hartnoll wrote:
> > You seem to be in two minds as to whether multiple exsl:result
> > elements should be allowed, perhaps to build up a compound result.
> > If you go the way you appear to be leaning, and only allow a single
> > instantiation then immediate termination would also solve all the
> > issues about what to do when multiple result elements are
> > instantiated - it just won't happen!
>
> I think these bring out very good points.
>
> exsl:return would imply that the function was immediately terminated,
> and imply that things like:
>
> <exsl:function name="math:min">
> <xsl:param name="nodes" />
> <xsl:if test="not($nodes)">
> <exsl:return select="-(1 div 0)" />
> </xsl:if>
> <exsl:return select="number($nodes[not($nodes < .)])" />
> </exsl:function>
>
> would work fine - if there aren't any nodes in $nodes then it should
> *return*, terminating the function.
>
> But having an instruction terminate processing of a template (rather
> than teminate the processing of the entire stylesheet) is a real
> change from how XSLT works. For example (this is nicked from Mike Kay
> off list):
>
> <xsl:function ...>
> <xsl:for-each select="$param">
> <xsl:if test="@id='3'">
> <exsl:return select="@name"/>
> </xsl:if>
> </xsl:for-each>
> </exsl:function>
>
> Usually a processor could go through all the nodes in $param in
> parallel and arrange their results in order when it's done. If we say
> that the exsl:return function *terminates* the function, then working
> through in parallel isn't an option any more - it *has* to go through
> them in order to find the first one.
>
> So I don't think that exsl:return should terminate the function.
>
> And personally I think that means that it shouldn't be called
> exsl:return or have any connotations that the function is terminated
> (which unhappily I think that exsl:return-value does too). I think
> that it will cause confusion amongst the majority who will not read
> the definition closely.
>
> I think we need an imperative term that doesn't imply that the
> function terminates. exsl:result-in, exsl:fix-result,
> exsl:set-result... others?
Yes. The fact that exslt:result does not terminate the function is one of the
reasons for my preference.
If we go with arguing for XSLT congruence, exsl:result wins again because
everywhere else in XSLT, flow-of-control is ultimately determined by content
model, rather than imperative instruction (xsl:goto, anyone?)
I certainly think the termination point for exsl:function should be defined by
the content model, not the location of exsl:result. This would make the name
"exsl:return" confusing, IMO.
And, ixnay on the "exsl:set-result" or "exsl:fix-result". This fails in the
alanogue to "xsl:variable", "xsl:param" and "xsl:key" that I already mentioned.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list