[Bug 11352] %nondeterministic and independent compilations of modules

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11352

Mary Holstege <holstege@mathling.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |holstege@mathling.com

--- Comment #5 from Mary Holstege <holstege@mathling.com> 2010-12-02 15:00:37 UTC ---
(In reply to comment #4)
> 
> 1. Require an implementation to raise an error if the functions determinism (as
> determined by static analysis) does not match its declaration. This is my
> preferred option.
> 2. If we can't get consensus for that, allow an implementation to raise an
> error in this case, and specify the error. Make it implementation-defined
> whether the error is actually raised.
> 
> I'm not convinced that the default should be 'deterministic'. Given the
> definition of deterministic in F&O, it's easy enough to determine, statically,
> whether a function is deterministic or not. Perhaps we should simply require
> implementations to do so?

I am opposed to either requiring the error or changing the default.  It is
perfectly reasonable to label a deterministic function as non-deterministic:
maybe it is a stub that is expected to be non-deterministic when the full
implementation is done, or maybe it is an attempt to see what the performance
implications of the use of a non-deterministic function would be.  It is also
perfectly reasonable to label a function which is technically non-deterministic
as deterministic. Consider a function that constructs a sequence of nodes and
then applies some path expression on them, so they return in document order.
Well, document order is undefined and therefore technically non-deterministic
in this case. Maybe, however, the developer knows that in the full context of
the use of this application that non-determinism makes no material difference
to the execution of the program. I see no reason why we should force an error
because a human was smarter than a static analyzer and wanted to provide an
optimizer hint.  

For usability and compatibility reasons, the default should not be
non-deterministic, as that requires people with existing modules to either have
to rewrite every single function in them in order to use that module in a 3.0
processor just to get the same performance characteristics as before.  This
forced change would be doubly bad because it would only show up as a mysterious
performance hit and the fact is that most functions in XQuery are
deterministic. We should choose defaults to match reality.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 2 December 2010 15:00:45 UTC