[Bug 1705] New: [FS] technical: 5.2 Module Declaration: cyclical imports

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

           Summary: [FS] technical: 5.2 Module Declaration: cyclical imports
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


5.2 Module Declaration

"Note that the rule above and the rules for static/dynamic processing of
an "import module" declaration in [5.11 Module Import] are mutually
recursive."
    Yes, and it seems to me that if you attempt to perform SCP or DCP on
    cyclically-importing library modules, the inference will not
    terminate.
    Consider the simplest case: main module M imports namespace N, which
    is the target namespace of library module L, which also imports its
    own target namespace N (explicitly allowed by XQuery 4.11).
    SCP of M's "import module N" relies on
        N =>module_statEnv statEnv1
    which relies on
        L =>stat statEnv
    which involves SCP of L's "import module N",
    which relies on
        N =>module_statEnv statEnv1
    etc.

    To handle this, I think you need another phase (call it Export Context
    Processing), a cursory version of SCP:
        Go through the Prolog, collecting all the "exportable" items
        (variables and their types, functions and their signatures).
        You might call the result an "export environment". The important
        thing is that this phase can skip over module imports, so it
        doesn't care about import-cycles.
    Some overarching mechanism would then be responsible for performing
    ECP on all library modules (of interest), and then using the
    resulting export environments to perform SCP on them all (wherein
    a module import simply pulls in the appropriate export environments).

    The only snag is that if a variable is declared without a type, its
    type must be inferred, which requires that its initializing expression
    be normalized and type-analyzed, which could involve imported
    variables or functions, and thus could not be done with the limited
    information available in ECP.

    For instance consider the two modules:
        --------
        module        namespace L1 = "http://www.example.com/foo";
        import module namespace L2 = "http://www.example.com/foo";
        declare variable $L1:s1 = $L2:s2;
        declare variable $L1:d1 = 10.0;
        --------
        module        namespace L2 = "http://www.example.com/foo";
        import module namespace L1 = "http://www.example.com/foo";
        declare variable $L2:d2 = $L1:d1;
        declare variable $L2:s2 = "foo";
        --------
    Note that there is no circularity involved in evaluating the
    variables:
        $s1 = $s2 = "foo"
        $d2 = $d1 = 10.0
    so err:XQST0054 is not applicable. (Or maybe it is; depends on what
    "circularity" means.) But just inferring their types seems pretty
    tricky.

    Perhaps you need to require that, in a library module, a variable
    declaration must have an explicit type. Or if that's too restrictive,
    say it can omit the type as long as the initializing expression
    doesn't depend on imported variables or functions. Or if that's still
    too restrictive, say it can't depend on variables or functions
    defined in another library module with the same target namespace.

    Or maybe just say that if an initializing expression cannot be
    statically typed because of a circularity, then that's an error too.

Received on Monday, 18 July 2005 05:24:54 UTC