[
Lists Home |
Date Index |
Thread Index
]
Yes, I think you are right. I thought about this again last night and came
to the same conclusion.
Michael Kay
http://www.saxonica.com/
> -----Original Message-----
> From: Daniela Florescu [mailto:dflorescu@mac.com]
> Sent: 06 December 2004 06:41
> To: Michael Kay
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] [XQuery] FLWOR
> (for-let-where-order-return) equivalent to FOR (for-order-return)?
>
> > The let clause is also redundant because references to the
> > variable can be replaced by the expression to which the variable is
> > bound.
>
> I am not sure I agree Michael.
>
> To be strictly formal, LET is not syntactic sugar in XQuery.
> It is syntactic sugar in most pure functional programming languages
> (i.e. can be
> eliminated by the rule that you cite) but not in XQuery, due
> to at least
> two independent reasons:
> (a) side effects as result of node constructors and
> (b) context-sensitive semantics (e.g. namespaces and unordered{..})
>
> Here are a couple of counter-examples.
>
> (a) side effects as result of node constructors
>
> let $x := <a/>
> return fn:count(($x,$x)/.)
>
> returns 1
>
> while
>
> fn:count((<a/>, <a/>)/.)
>
>
> returns 2
>
> (b) context sensitive semantics due to unordered {...}
>
> let $x := (fn:doc("foo.xml")//a[@b=3])[1]
> return unordered { $x }
>
> is not equivalent to
>
> unordered {(fn:doc("foo.xml")//a[@b=3])[1]}
>
> The first one is deterministic, the second one not.
>
> But in reality few programmers will realize those small subtle
> differences.
> Moreover, a good compiler should be able to detect the cases where
> the rule you cite is applicable, and the apply it only under those
> circumstances.
>
> Best regards,
> Dana
>
> P.S> It is late in the night and I have no XQuery processor
> at hand to
> run and
> check those examples but I hope I got them right. I am
> sure you know
> what I
> mean anyway.
>
>
|
