Record types: extensible and non-extensible pairs

[michaelhkay]

It is often useful in a function signature for an argument type to be an extensible record type (so additional fields are allowed, which the function can ignore, saving the need to check for their presence) while the return type is non-extensible (giving better static type checking for lookup expressions, for example).

Currently this requires two separate named record types to be declared, differing only in that one of them is extensible and the other not. This duplication is clearly undesirable.

One solution to this might be to have a single non-extensible definition of the name of the record type, with some way of indicating at the point where the record type is used that extensions are allowed.

For example (probably not viable syntax as written):

fn:element-to-map-plan(
       $input as element()*   
) as fn:element-to-map-conversion-plan

fn:element-to-map(
       $node as element(),
       $plan as extensible fn:element-to-map-conversion-plan
} as map(*)

Perhaps the syntax extensible(fn:element-to-map-conversion-plan) would work.

[michaelhkay]

An alternative avenue might be to scrap the notion of extensible record types, and instead to specify that coercion to a record type drops undeclared fields.

[ndw]

Wouldn't dropping the undeclared fields prevent the original use case you cited of allowing additional fields to be passed to a function? I guess you could just use record(*) for those cases, but that means the function has to defensively check for all the "required" fields as well. That seems like an unfortunate compromise.

[ChristianGruen]

With regard to built-in record types, it may be most flexible to define all of them as extensible.

For user-defined records, we could extend named records with parentheses:

declare record my:coord(x, y);

declare function my:restrict($data as my:coord) as my:coord(*) { };
declare function my:extend($data as my:coord(*)) as my:coord { };

But from the user perspective, I am not sure what would be the advantages of introducing more syntax or stricter coercion rules. If a record will be extended by a function, I would define it as being extensible. If I want to enforce a strict structure, I would avoid extensibility.

Do you have a specific use case in mind?

[ndw]

I infer from what Mike wrote above that he'd like to be able to statically determine if thing in ex:f($rec)?thing was a key. If the return type is extensible, you can't know that it isn't. Conversely, if $rec is "the same" type, it's useful if it's extensible.

[ChristianGruen]

I infer from what Mike wrote above that he'd like to be able to statically determine if thing in ex:f($rec)?thing was a key. If the return type is extensible, you can't know that it isn't. Conversely, if $rec is "the same" type, it's useful if it's extensible.

From the implementer perspective, I can relate to it: record(x, y)?z can easily be simplified to an empty sequence at compile time if we know that the record does not contain z. But I am not sure what would be the advantages for users. It might be different if lookup expressions raised an error when entries do not exist: This error could then be raised at compile time or earlier.

What we do is to generate virtual records whenever existing records are extended. This way, the map:get('unknown') function call in the following query can be optimized to an empty sequence:

declare record local:coord(x, y);

local:coord(2, 3)
=> map:put('z', 4)
=> map:get('unknown')

Of course this approach is limited to keys that can be inferred statically, but it’s pretty powerful.