Re: review of "Evaluating Function Calls"

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²).

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


>--------------
>Maps + Arrays:
>
>Item 5.b.i says:
>     If F is a map, it is evaluated as described in 3.11.1.2 "Map Lookup
>     using Function Call Syntax". If F is an array, it is evaluated as
>     described in 3.11.2.2 "Array Lookup using Function Call Syntax".
>These two possibilities are disjoint, so maybe they should be separate
>points.
>
>Because maps and arrays are functions, one can presumably perform partial
>function application on them (though I think it would not generally be
>useful). Is the resulting function a map/array? E.g., consider:
>     let $m := map {"Su": "Sunday"} return ($m(?)) ? "Su"
>Does the lookup return "Sunday", or does it raise a type error? I don't
>think 3.1.5.1 gives a clear answer.


Good point.

I agree that it isnıt terribly useful to create maps or arrays as the
result of partial function application, but supporting it would be less
surprising than not supporting it. It would require more test cases.


>At the end of 
>https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0027.html,
>I said:
>> we need to be clearer about how arrays and maps fit into the world
>> of functions. (That is, we need to say more in the sections on arrays
>> and  maps, not just mention them in 5.b.ii's parenthetical list.)
>What I had in mind was that the Arrays + Maps sections could specify the
>properties of the function that is defined, as do the sections on
>Function 
>Decls and Inline Function Expressions. Which wouldn't necessarily answer
>the 
>above question, but might get us closer.

That makes sense.

Jonathan

Received on Monday, 18 April 2016 22:48:03 UTC