Add experimental module for Records and Variants indexed by type-level multimaps

[danidiaz]

Adding an entry and deleting it afterwards (useful for example when working with error-throwing functions which internally invoke other error-throwing functions with a "bigger" error type) can result in non structurally identical type-level maps, which is a pain.

A workaround for this problem is requiring a "subset" constraint, checking that all entries in one tree are present in another. The complexity is n log n at compile time, which seems quite wasteful given that we know the trees hold the same entries. Is there a better way?

Another problem with using Variants as error types is name collisions. What happens if one of the extra entries of the function with the "bigger" error type collides in its key with an entry already existing in the "smaller" error type? Combining error-throwing functions could fail because of internal details of the functions, which is awful (let's not consider the problem of key collisions at the "same level", which is still awful, if slightly less so).

These problems could be alleviated by using Variants indexed by type-level multimaps. Each key would correspond to a list (perhaps empty) of types, not to a single type.

For Records and Variants, the type at the head of each list would be the "active" one, others would be shadowed. That would correspond to inaccessible fields in Records (and perhaps something like uninjectable/unmatchable branches in Variants? I'm not sure.)

The global error type could have keys present but assigned to the empty list. If we added a type to that key, it would be added to the head of the list. If we later removed that type, we would end up with a map structurally identical to the one with which we started!

Another change: we could remove support for actually deleting keys from the type-level map. Instead, we would only allow setting existing keys to the empty type-level list.

Inserting would become more complex:

• inserting a key into the type level map, setting the value to the empty list (changes the map structure)
• inserting a key into the type level map, setting the value to a one-element list (changes the map structure)
• adding a type to the type-level list associated to a key (only changes the structure of the value list, not of the map)

A possible problem is that the concept of empty map becomes blurrier. We could have maps with lots of keys, all set to the empty list.