Re: Comments on the File Module

Yes, also whether:

let $a := file:append-text('foo.txt', ' cat')
let $b := ($a, file:append-text('foo.txt', 'fish') )
return ($b, $a)

might be used to enforce the order-dependency, although I think Tim's 
original example is preferable on the face of it, assuming it doesn't 
cause deeper problems.

And I think one would like to know what

let $a := file:write-text('foo.txt','cat')
let $b := file:read-text('foo.txt')
let $c := file:write-text('foo.txt','fish')
let $d := file:read-text('foo.txt')
return ($a, $b, $c, $d)

can be expected to return (assuming no third party file writer), ie:  
are writes buffered? immediate, ordered? It would be good to have a 
consistent approach there I think.  Obviously users will expect ('cat', 
'fish'), but it would also be consistent to buffer writes until a 
post-evaluation phase to try to preserve immutability?

-Mike


On 12/09/2013 11:56 AM, Tim Mills wrote:
> 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 17:04:28 UTC