[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[exsl] Naming exsl:return/exsl:result (Was: Re: [xsl] Functional programming in XSLT)

---

---

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?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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

---