[Bug 11352] %nondeterministic and independent compilations of modules

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

--- Comment #2 from Daniela Florescu <dflorescu@mac.com> 2010-11-20 01:23:49 UTC ---
Mike,

everything you said WOULD work, if modules would be required to disclose
that information about their publicly exposed functions (signature AND semantic
properties/annotations), and then stick to what they declared in the first
place.

But they DON'T today. Only signature is required. Semantic properties are left
in the air.

If a function f() is calling another function g() in an another module, and g's
body definition
changes (e.g. changes from being deterministic to being non-deterministic), so
does f()'s, as a side-effect. And changes in the semantic definition of f()
mean different optimization/indexing/caching/etc.

Let me try to be more explicit: changes in the BODY of a function in ONE module
(not visible signature)
in a module can have effect on the semantics/compilation/optimization of
ANOTHER module.

That's not what I call independent compilation of modules.

Hence my blocking bug request.

This is not a good foundation for a modern programming language.

Example:

module 1.
==========

module namespace ns1= uri1;

import module namespace ns2=uri2;

declare function ns1:foo1()
{
    ns2: bar1()
}


declare function  ns1: foo2()
{    
    ns2:bar2()
}



module 2
========


module namespace ns2= uri2;

import module namespace ns1=uri1;

declare function ns2:bar1()
{
    ns1: foo2()
}


declare % nondeterministic function  ns2:bar2() external;


================

Neither one of the two modules can be compiled without the ***content**** of
the other module,
(I am talking here about signatures and/or headers) which is terribly bad.

If I change the ns2:bar2 to be %deterministic, this changes the
semantics/optimization/runtime/indexing/
caching/etc of both ns1:* functions !

I deal with tens of thousands of lines of XQuery right now, and that's a
blocking bug.

Thanks for taking it seriously, best regards
Dana

-- 
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 Saturday, 20 November 2010 01:23:52 UTC