Re: [exsl] Naming exsl:return/exsl:result (Was: Re: Fu

> 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 &lt; .)])" />
> </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@xxxxxxxxxxxxxxx               +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