[Bug 3883] [FS] editorial: 4.1.5 Function Calls / Static Type Analysis

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

           Summary: [FS] editorial: 4.1.5 Function Calls / Static Type
                    Analysis
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


4.1.5 Function Calls

STA

"categories the belong to"
    s/the/they/

"looking-up"
    s/-/ /

"The following two rules ... by first looking-up the expanded QName for
the function, then applying the appropriate set of static typing rules
depending on the category in which the function is."
    That doesn't describe what these two rules do, it describes what the
    subsequent prose (with the three-way split) does.

"check that some signature for the function satisfies the following
constraint: the type of each actual argument is a subtype of some type
that can be promoted to the type of the corresponding function parameter."
    Old wording. Change to:
        "check that the type of each actual argument can be promoted to
        the type of the corresponding function parameter."

"Notice that the static context contains at most one function declaration
for each function."
    Well, strictly speaking, it contains at most one function signature
    for each (function name, arity) pair. It would be more approriate to
    say this earlier, after "look up the function in the static
    environment".

"This [the fact that there's at most one signature pertinent to a
FunctionCall] is possible since the treatment of overloaded operators is
done through a set of specific static typing rules which do not require
access to the environment."
    While it's true that the overloaded fs: functions have special static
    typing rules, it isn't true that:
    a) they do not require access to the environment, or
    b) their special treatment "makes it possible" for statEnv.funcType
       to map to a single signature.
    Moreover, they're not really relevant at this point, since the
    three-way split has already dispatched them to C.2.
    (This sentence is a leftover, delete it.)

Received on Sunday, 29 October 2006 10:42:10 UTC