This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Designs for XSLT functions (Was: Re: RE: syntax sugar for call-template)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: Designs for XSLT functions (Was: Re: [xsl] RE: syntax sugar for call-template)
- From: Joe English <jenglish at flightlab dot com>
- Date: Tue, 20 Feb 2001 19:06:24 -0800
- Reply-To: xsl-list at lists dot mulberrytech dot com
Uche Ogbuji wrote:
> > > The only thing to consider about this is that it introduces a side effect
> >
> > No, it doesn't. However, in languages where you otherwise have
> > side effects (like C) you have to think extra carefully about the
> > evaluation order.
>
> My exact point is that an exsl:if function as you describe above *does*
> introduce an order-of-execution side effect.
The effect Uche is talking about isn't usually called
a "side effect"; it's usually called "strictness"
or "non-strictness". To work properly, 'exsl:if'
would have to have non-strict semantics, but the most
natural implementation of extension functions uses
strict semantics.
<digression>
A good illustration of strict vs. non-strict semantics is
'AND' vs. 'AND THEN' in Ada. 'AND THEN' is the "short-circuit"
version of the boolean AND operation, analogous to '&&' in C.
Denotationally speaking, both operators have type
(Boolean x Boolean -> Boolean), where (denotationally speaking)
the type 'Boolean' has three possible values: 'True', 'False',
and '_|_'. 'True' and 'False' are the familiar logical values,
and '_|_' is an extra element adjoined to the domain
to represent non-termination and error conditions.
The operators are defined as:
x AND y:
x\y| T F _|_
==================
T | T F _|_
F | F F _|_
_|_ | _|_ _|_ _|_
x AND THEN y:
x\y| T F _|_
==================
T | T F _|_
F | F F F
_|_ | _|_ _|_ _|_
The difference between the two is that 'False AND THEN y'
is always 'False', but 'False AND y' is '_|_' (i.e., fails
to terminate, raises an error, etc.) if 'y' is '_|_'.
</digression>
> That is why if an exsl:ternary
> is debated, I would vote that all arguments must be evaluated regardless of
> the value of the selector.
In other words, strict semantics. Sounds reasonable.
--Joe English
jenglish@flightlab.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list