Re: Further thoughts on enabling unprefixed function calls

<grin/> I thought Mike would be able to put this in spec'ese.

Polite request no Mike.
  Some examples please - user view?

regards

On Mon, 30 Nov 2020 at 09:36, Michael Kay <mike@saxonica.com> wrote:
>
> I'm thinking now along the following lines:
>
> (1) as well a having an optional full name (which is a QName), a function may have an optional method name (which is an NCName). In the vast majority of cases the method name will be the local part of the full name.
>
> (2) in a static function call, and on the RHS of the arrow operator, an unprefixed function name searches first for functions where (a) there is a matching method name, (b) the arity matches, and (c) the type of the first argument (as supplied, dynamically) matches the declared type of the first parameter. (Function references such as math:sin#1 must still be prefixed, however, and function-lookup would work only on the namespace-qualified name.)
>
> (3) if there are two such functions F and G, eliminate F if the declared type of the first argument of F subsumes the declared type of the first argument of G. Repeat as necessary. If this leaves one function, choose that one. If it leaves more than one, raise a type error.
>
> (4) if the search for a matching method name is unsuccessful, search for a function with the required name in the default namespace, as now. This is needed only as a fallback.
>
> (5) for all functions in the fn, math, map, and array namespaces, give the function a method name equal to the local name of the function, except where this would cause incompatibilities with existing code. Resolve these cases by assigning a different method name: for example map:remove acquires a method name of "drop". (In fact, to avoid confusion, introduce a new function map:drop() with the same behaviour as map:remove; map:remove remains available, but has no method name, so cannot be used unprefixed. )
>
> (6) we can take advantage of the new rules by introducing method names such as format() which does format-number(), format-date(), format-time(), or format-dateTime() depending on the type of the first argument.
>
> The effect of these rules is that you can now write, for example $m => put('x', 3) rather than $m => map:put('x', 3), and you can write sin($angle) rather than math:sin($angle). It's fine to have two functions with method name "put" (map:put and array:put) because the type of the first argument in the two functions is disjoint. sin($angle) works simply because the local name is unique. The cases that aren't OK are where the function has the same name as a function in the fn namespace and the declared types overlap.
>
> User-written functions become eligible for the same treatment: with some kind of syntax to enable the feature, user-declared functions become eligible for calling by local name alone provided the name resolves without ambiguity. Applications can exploit the mechanism to achieve polymorphism, with functions on derived types overriding functions on their base types. But we should make sure this doesn't happen by accident.
>
>
> Note that the algorithm given for resolving function name uses run-time type information. However, the hope is that in the vast majority of cases, it would be possible to identify the right function statically, either because the name is unambiguous, or because there is enough static type information to disambiguate the reference.
>
> You still get a static error if there are no functions in the static context with a matching name; it's only the case where there are multiple such functions that require run-time resolution.
>
> Michael Kay
> Saxonica



-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

Received on Monday, 30 November 2020 09:53:03 UTC