Re: Comments on the File Module

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
>