W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2015

[Bug 27918] serialization output for functions

From: <bugzilla@jessica.w3.org>
Date: Wed, 28 Jan 2015 12:43:22 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27918-523-h3ktYi75Wi@http.www.w3.org/Bugs/Public/>

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
XDM states that a function has the following properties:

* name (xs:QName): An expanded QName, possibly absent.
* parameter names (xs:QName*): A list of distinct names, one for each of the
function's parameters.
* signature (a FunctionTest of the form Annotation* TypedFunctionTest): The
TypedFunctionTestXP31 has one SequenceTypeXP31 for each parameter, and one
SequenceType for the function's result....
* implementation This enables the function, when it's called, to map instances
of its parameter types into an instance of its result type. The implementation
is either:
a host language expression, which is always associated with a static context,
an implementation-dependent function implementation, which is optionally
associated with both a static and a dynamic context.
* nonlocal variable bindings (a mapping from xs:QName to item()*): This
provides a value for each of the function's free variables (i.e., variables
referenced by the function's implementation, other than locals and parameters).

The problem is, (a) much of this isn't actually available using accessors on
the function item, and (b) part of it doesn't have an obvious string

I'm not sure why the parameter names are in this list, because there is no need
for an implementation to retain the names of the parameters. Perhaps it's
needed for the formal modelling of the semantics. However, I don't think we
should require implementations to retain the parameter names just for the sake
of serialization.

The implementation is an even bigger problem: I don't think we can require
implementations to have a decompiler that reconstructs source code from
compiled code.

As for nonlocal variable bindings, an implementation might well inline variable
references within the function body, replacing them by the values to which the
variables are bound.

We could possibly include the types of arguments and the result in the
serialized form, but I don't think we can add much else.

We could also possibly PERMIT implementations to include further information
about functions, while leaving the detail implementation-defined.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 28 January 2015 12:43:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:52 UTC