Propose Type Aliases

[adamretter]

Often I find that I want to have a name alias for a complex type definition. This would be particularly helpful in a number of scenarios:

1. When defining an API, it would be nice to have a more descriptive name for the users of the API. I believe that this can increase code readability.

2. Less typing, some type definitions are quite complex, a simple alias could reduce the amount of copy-paste semantics.

Suppose I have a function that takes an argument which is rather complex:

declare function local:my-function($a as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+)

It would be easier/nicer if I could have something like the following:

declare type alias local:lazy-math-functions
    as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+;

declare function local:my-function($a as local:lazy-math-functions) {
...
};

declare function local:my-other-function($a as local:lazy-math-functions, $b as xs:int+) {
...
};

Aliases are likely only syntactic sugar, they are not types themselves. The query processor should always report errors based on the real types, of course if the processor wants to keep the name of the type alias around for better error reporting, then it is free to do so.

We could also consider the vsisibility of type aliases of a module, perhaps we want to allow %public and %private like annotations.

[michaelhkay]

Something like this, you mean? http://www.saxonica.com/documentation/index.html#!extensions/syntax-extensions/type-aliases Also discussed here: http://dev.saxonica.com/blog/mike/2016/09/tuple-types-and-type-aliases.html I think I started drafting an EXPath proposal on this, but got distracted by other things. Mike

…

On 30 Nov 2018, at 05:04, Adam Retter ***@***.***> wrote: Often I find that I want to have a name alias for a complex type definition. This would be particularly helpful in a number of scenarios: When defining an API, it would be nice to have a more descriptive name for the users of the API. I believe that this can increase code readability. Less typing, some type definitions are quite complex, a simple alias could reduce the amount of copy-paste semantics. Suppose I have a function that takes an argument which is rather complex: declare function local:my-function($a as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+) It would be easier/nicer if I could have something like the following: declare type alias local:lazy-math-functions as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+; declare function local:my-function($a as local:lazy-math-functions) { ... }; declare function local:my-other-function($a as local:lazy-math-functions, $b as xs:int+) { ... }; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSIIrihp2LNE1OOjjePT9RFxooz8mKJks5u0LxFgaJpZM4Y7A92>.

[michaelhkay]

Note also that John Snelson proposed a similar idea in the WGs at one stage. I'm not going to search for his proposal right now, but IIRC he did discuss the possibility of making this a little more than just an "alias" or macro. (a) you could try to have stronger encapsulation so the named type exposes a limited set of operations on the data (e.g. a temperature is a double, but you aren't allowed to multiply two temperatures) (b) you could allow recursive type definitions, so for example a binaryTree is a tuple containing (left as binaryTree?, payload as item()*, right as binaryTree?). I have also suggested in the past defining types by restriction, e.g. type currency is xs:string [. = ("USD", "EUR", "CAD", "GBP")] Note this is different from XSD subtyping in that the value doesn't need to be annotated/validated as belonging to the type; rather, the (type matches item) condition evaluates the predicate on the supplied value. However another way of meeting the goal would be to allow casting in the function conversion rules: declare function payMe ($amount as xs:decimal, $currency castable as my:currency) would allow payMe(64000, "USD") provided "USD" is castable as my:currency. Michael Kay Saxonica

…

On 30 Nov 2018, at 05:04, Adam Retter ***@***.***> wrote: Often I find that I want to have a name alias for a complex type definition. This would be particularly helpful in a number of scenarios: When defining an API, it would be nice to have a more descriptive name for the users of the API. I believe that this can increase code readability. Less typing, some type definitions are quite complex, a simple alias could reduce the amount of copy-paste semantics. Suppose I have a function that takes an argument which is rather complex: declare function local:my-function($a as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+) It would be easier/nicer if I could have something like the following: declare type alias local:lazy-math-functions as (function() as map(xs:string, map(xs:string, (function(xs:integer) as xs:float+)*)))+; declare function local:my-function($a as local:lazy-math-functions) { ... }; declare function local:my-other-function($a as local:lazy-math-functions, $b as xs:int+) { ... }; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACSIIrihp2LNE1OOjjePT9RFxooz8mKJks5u0LxFgaJpZM4Y7A92>.

[adamretter]

@michaelhkay Ah Ha. Yes almost exactly like what Saxon has for type aliases :-)

Not too sure about types by restriction, we are effectively then attaching a validation function to type values. I need to give it some thought and consider it in the context of things like Refined Types - https://github.com/fthomas/refined#related-projects

[adamretter]

I would also like to propose function aliases:

declare function alias xdmp:log($msg, $level) := util:log($level, $log)

This is useful where you have a function whose context is important, another example would be fn:error.