Re: Comments on the File Module

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.

On this matter, the XQuery specification only says

"However, unlike a pure functional language, it does not allow variable 
substitution if the variable declaration contains construction of new 
nodes."

suggesting that it permits variable substitution otherwise.

Cheers,
     Tim

On 09/12/2013 16:26, Christian Grün wrote:
> It’s true that the functions in the File Module that are flagged as
> nondeterministic may not be relocated. As there are many other EXPath
> functions with the same restriction, and as I believe there will be
> more and more side-effecting functions in the future, the definition
> of the ·nondeterministic· flag should probably be moved out of the
> File Module and placed at a more central location, such as the XQuery
> 3.0 Functions Spec.
>
> The current definition of ·nondeterministic· functions in the XQuery
> 3.0 Spec is pretty short:
>
> • A function that is guaranteed to produce ·identical· results from
> repeated calls if the explicit and implicit arguments are identical is
> referred to as deterministic.
> • A function that is not ·deterministic· is referred to as ·nondeterministic·.
>
> In my point of view, this definition may not even hold for the
> fn:error function, which is also marked as ·nondeterministic·,
> although it “produce[s] ·identical· results”.
>
> Maybe we should discuss what ·nondeterministic· means to us, what we
> need it for, and if it is an appropriate flag for side-effecting
> functions at all. We could think also about introducing new flags, but
> it usually makes things more complicated as long as we are not 100%
> sure why we are doing it.
>
> Thanks,
> Christian
> ___________________________
>
> On Mon, Dec 9, 2013 at 4:36 PM, Michael Kay <mike@saxonica.com> wrote:
>> I think the file module relies on some implicit semantics for side-effecting function calls. These are troublesome but at the same time widely available in current products, and I think the best we can do is to acknowledge that the dependency exists and live with it. I don't think the EXPath community should attempt the formalization of the semantics of such calls.
>>
>> Clearly functions like file:append() depend not only on the function call not being optimized away, but also on different function calls being executed in a predictable order. Achieving this may require implementation-dependent pragmas or configuration options, for example in Saxon it's probably a good idea to suppress multi-threading, or at least to understand Saxon's multi-threading well enough to ensure that all your calls are in the same thread.
>>
>> The rule in XQuery static typing about expressions that return an empty sequence clearly doesn't work for these function calls, and implementations that implement this static typing rule are going to have to manage around this.
>>
>> We wouldn't be able to define these functions in the formal language spec, because the foundations are too shaky. But we can do it in EXPath: It just means that implementations either have to build their own foundations to support this stuff, or document the extent of the shakiness, or decide not to implement it.
>>
>> Michael Kay
>> Saxonica
>>
>>
>> On 9 Dec 2013, at 15:06, Florent Georges <fgeorges@fgeorges.org> wrote:
>>
>>> On 6 December 2013 19:12, Tim Mills wrote:
>>>
>>>   Hi Tim,
>>>
>>>> Thank you for your work on this specification.
>>>   Thank you for your interest and comments.
>>>
>>>> The introduction of non-deterministic functions is a worry (although
>>>> inevitable given the purpose of the specification).  Is your
>>>> statement
>>>> "Some function are marked as ·nondeterministic·, which means they
>>>> are not guaranteed to perform the same operations and produce
>>>> identical results from repeated calls. A query processor must ensure
>>>> that these functions are not relocated or pre-evaluated and that its
>>>> results are not cached when compiling and evaluating the query and
>>>> serializing its results."
>>>> enough?  If I understand XQuery correctly, the specification doesn't
>>>> mandate an order of evaluation.  For interoperability with
>>>> non-deterministic functions, isn't such an ordering required?
>>>   Christian and Matthias, correct me if I am wrong, but I think the
>>> idea here is not to define an order of evaluation, but to ensure that
>>> the expression is no "optimized away".  Of course, this is kind of
>>> complex to define in XPath (or XQuery or XSLT).  But for the order of
>>> evaluation, I think the idea is more to introduce a functional
>>> dependency where you need one.
>>>
>>>   It would be interesting to see if it is possible to create a
>>> functional dependency everywhere we need one, given that some
>>> functions return nothing and/or take no parameter.  Especially since
>>> when we decided to not have a "file handler" (a kind of black box item
>>> that would be returned by file:open, and passed to most functions in
>>> the same module, so to create a functional dependency between all
>>> calls involving the same file).
>>>
>>>> I'm also concerned by the use of functions which return a signature
>>>> of empty-sequence(). since XQuery/XPath permits an implementation to
>>>> raise error XPST0005 in such cases.
>>>   Interesting.  Actually, the XPath spec defines this error in order
>>> to catch potential typos in schema-enabled processing, making the
>>> assumption that an expression that we know till return nothing will
>>> be, in all possible cases, an error (the corollary of which being that
>>> an expression cannot be called only for its side effect).  The absence
>>> of an "empty sequence" SequenceType, in XPath 2.0, was consistent with
>>> that approach.
>>>
>>>   But it does not look anymore consistent to me with having the new
>>> SequenceType "empty-sequence()" in XPath 3.0.  Especially with the
>>> ability of declaring a function (in XQuery and XSLT)the return type of
>>> which being "empty-sequence()".
>>>
>>>   Should not that be considered a bug in XPath 3.0?
>>>
>>>   Regards,
>>>
>>> --
>>> Florent Georges
>>> http://fgeorges.org/
>>> http://h2oconsulting.be/
>>>
>>

Received on Monday, 9 December 2013 16:48:06 UTC