Re: Comments on the File Module

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.

Cheers,
   Tim

> On 9 Dec 2013, at 20:38, Christian Grün <christian.gruen@gmail.com> wrote:
> 
> @Tim: Back to your original question…
> 
>> It needs to be made clear whether writing
>> 
>> let $a := file:append-text('foo.txt', ' cat')
>> let $b := file:append-text('foo.txt', 'fish')
>> return ($b, $a)
>> 
>> is guaranteed to produce "fish cat", " cat fish", or whether there is no
>> such guarantee - because undoubted someone will write this.
> 
> According to the current definition of non-determinism in the File
> Module, there should be no doubts that the function order is
> preserved. If we decide to revise the definitions, this guarantee
> should by all means be preserved.
> 
> And @Florent:
> 
>> I think the idiomatic solution is to create an explicit dependency
>> between the calls, by returning "something" from the functions that is
>> taken as a parameter as well, as explained there:
>> 
>> http://lists.w3.org/Archives/Public/public-expath/2012Aug/0000.html
> 
> I remember I tried to draft such a proposal. Function chaining feels
> like a straightforward approach first, but things get complicated when
> use cases are getting more complex. As an example, I wondered if
> operations like file:delete are supposed to return a value, how
> operations should be treated that already return values, or how
> file:move or file:copy should be properly handled, let alone all
> operations in general that affect more than a single file. Beside
> that, we have no canonical way to "swallow" returned ids that are of
> no further use. In BaseX, we have introduce a void() function, which
> does exactly that; once again, this function is flagged as
> nondeterministic.

Received on Monday, 9 December 2013 20:51:43 UTC