Re: review of "Evaluating Function Calls"

On 16-04-18 06:47 PM, Robie, Jonathan wrote:
> On 4/18/16, 5:18 PM, "Michael Dyck" <jmdyck@ibiblio.org> wrote:
>
>> -----
>>
>> In step 5, the change (at various points) from wording like:
>>      function implementation is [not] a FunctionBody
>> to:
>>      function implementation is [not] an &language; expression
>> is not in sync with the "Inline Function Expressions" and "Function
>> Declaration" sections, which still say that the resulting function's
>> implementation is a FunctionBody. I'd be inclined to undo the change in
>> 3.1.5.1, as I don't think it's an improvement.
>
> I prefer to change it to &language expression throughout, since that¹s
> what the XDM says an implementation is in this case ("a host language
> expression, which is always associated with a static context²).

If you feel constrained by that, I'd prefer to change the data model. I 
agree with Mike Kay that the data model is over-specific on this point. 
(Note that the Data Model's definition of function implementation is the 
only place in the DM doc that refers to a "host language expression", the 
only place that refers to a "dynamic context", and the only place outside a 
Note that refers to a "static context". To me, this strongly suggests that 
that definition is overstepping the DM's normative bounds.)

Ref Mike Kay's suggestions:
https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0009.html

> Saying it is a FunctionBody implies that there is some distinction between
> a function body and its content expression in the data model.

Not at all. Both are syntactic constructs, and so do not even exist in the 
data model.

>> --------------
>> Maps + Arrays:
>
> I agree that it isn¹t terribly useful to create maps or arrays as the
> result of partial function application,

Hold on, you're agreeing with not quite what I said. To reword: I think it 
wouldn't be useful for a user to perform PFA on a map or array, but I think 
the spec is obliged to define what it means anyway. But whether that creates 
a map or array is the question I'm asking.

To put it differently, there's a succession of questions for the WG to decide:

(1) Does the spec need to define the semantics of PFA on a map or array?

I don't see how it can avoid it. (Well, I suppose we could say that the 
semantics are implementation-defined/dependent.)


(2) If answer to #1 is yes, does it do so already?

I don't think it does. You end up asking the question: if every map is a 
function, then how do we determine whether a given function [i.e., the 
function created by the evaluating the PFA] is a map? Ditto array.

If you ask the analogous question "if every attribute node is a node, how do 
we determine whether a given node is an attribute node?" then the answer is 
easy: use the dm:node-kind() accessor.

Or "if every xs:integer is an xs:decimal, how do we determine whether a 
given xs:decimal is an xs:integer?" I think the answer is in in the 
definition of atomic value: "An atomic value is a value in the value space 
of an atomic type and is labeled with the name of that atomic type." So you 
just have to inspect that label for the value you have in hand.

But I don't see an answer to the map/array/function case.

(Interestingly, DM sections 2.8.2 "Map Items" and 2.8.3 "Array Items" don't 
mention their relation to function items. That only appears up in 2.7.4, 
which says that array(*) and map(*) are derived types of function(*).)


(3) If the answer to #2 is no, then what should the semantics be?

Beats me.

-Michael

Received on Tuesday, 19 April 2016 03:56:08 UTC