Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@m...] > Sent: 06 December 2004 06:41 > To: Michael Kay > Cc: xml-dev@l... > Subject: Re: [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. > >
|
