Re: Comments on the File Module

Thanks for the discussion. To complement this: In BaseX, if the
·nondeterministic· flag is set, no rewritings will take place that
will change the expression order of the unoptimized expression tree,
in which the order of flwor clauses, the order of expressions
separated by commas, etc. equals the left-to-right and top-to-bottom
string representation from the original XQuery expression. Things look
different for deterministic expressions, which may lead to completely
different query plans.

I would be interested to hear how the challenges are tackled in other
implementations? (Anyone from eXist-db? Zorba? et al.)

Christian
___________________________

On Tue, Dec 10, 2013 at 11:17 AM, Michael Kay <mike@saxonica.com> wrote:
> The advice I give for Saxon users is, if you're going to use external
> functions with side-effects, then call them at a point where, if they
> returned a text node, that text node would be written to the result tree.
> The order of execution will then be the order in which the text nodes would
> be written if they existed.
>
> This is not dissimilar from the rules enforced for xsl;result-document in
> XSLT.
>
> I guess the challenge here is to find some technique that is guaranteed to
> work across processors.
>
> The most pressing need is to ensure that
>
> for $x in SEQ return file:append-text('foo.txt', f($x))
>
> works in the way users are likely to expect. We clearly can't offer that
> guarantee without changing the semantics of "for" expressions.
>
> We could define a function sequential(f) that takes a "void" function as
> input and returns a function based on f that takes a sequence number as an
> extra argument and returns a new sequence number, and then one could write
> fold-left(SEQ, 0, sequential(file:append-text#2)('foo.txt', ?)). Or
> something like that. But would anyone use it?
>
> Michael Kay
> Saxonica
>
> On 10 Dec 2013, at 09:51, Tim Mills <tim@cbcl.co.uk> wrote:
>
> On 09/12/2013 21:42, Christian Grün wrote:
>
> let $a := file:append-text('foo.txt', ' cat')
> let $b := file:append-text('foo.txt', 'fish')
>
> I'm not sure what you mean by function order - and I think that's my point.
> XQuery doesn't define an order of evaluation.
>
> Pardon my broken English. By function order, I meant to say that '
> cat' must be appended to the file 'foo.txt' before 'fish'.
>
>
> I didn't mean to suggest it was your English (which is superb), I was just
> making the point that function order isn't something that has been defined.
> When reading a program, the programmer is conditioned to perceive an order
> based on the usual left-to-right, top-to-bottom order of languages such as C
> (or even ML), but anyone who's looked at the execution plan that comes out
> of an XQuery processor knows that the order may not be preserved.
>
> I guess we are talking about a similar thing: On the one hand, the
> current version of XQuery provides no means to enforce evaluation
> order. On the other hand, varioous XQuery processors are available
> that provide an implementation of the File Module, or other
> side-effecting modules, and that assume that code (may it be
> ·nondeterministic· or ·side-effecting·) is evaluated in the order in
> which it’s specified in the query (as part of a FLWOR expression, as
> multiple expressions separated by commas, or any other way). How can
> we resolve this discrepancy?
>
>
> The stalled XQuery Scripting Extensions proposed an order of evaluation, so
> that's one approach;
> the monadic approach of Haskell is my personal favourite; then there's the
> "programmer beware" approach of hoping that the processor doesn't reorder
> expressions.
>
> The foolhardy programmer might write
>
> <xsl:attribute
>   name = "{ (file:append( ...), 'foo') }"
>   namespace? = "{ (file:append ( ...), 'urn:something') }
>   select? = "{ (file:append (...), 'red') }"
>   on-empty? = "{ (file:append (...), 'empty') }"  />
>
> Either it has to be clear that all bets are off, or an order of evaluation
> has to be defined.
>
> Cheers,
>     Tim
>
>
>

Received on Tuesday, 10 December 2013 15:11:11 UTC