- From: Christian Grün <christian.gruen@gmail.com>
- Date: Mon, 9 Dec 2013 21:38:50 +0100
- To: Tim Mills <tim@cbcl.co.uk>
- Cc: Michael Kay <mike@saxonica.com>, Florent Georges <fgeorges@fgeorges.org>, EXPath CG <public-expath@w3.org>
@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:39:37 UTC