Should multiple-value static infos live under a key?

[usaoc]

Currently, multiple-value static infos live under #%values/statinfo_meta.values_key, but I think some aspects of them make them different than other genuine static info:

• Static infos of different arity are incompatible, and their combination renders the whole package invalid;
• Manipulation of static infos, such as union and intersection, must be aware of the arity;
• #%values cannot be combined with other keys in any meaningful way;
• Lookup should simply fail when the static infos are for anything other than arity 1.

Does it make more sense to revise the representation of static infos to accomodate for multiple-value cases? The drawback is, of course, more verbose manipulation for the most common case of arity 1.

[mflatt]

Possibly something to consider at the same time: Should each static-info key should be bound to a compile-time value that implements intersection and union operations for the key?

[mflatt]

When revising the representation of static information to use a binding to compile-time union and intersection functions (ef71819), I did not find a better way to handle this than #%values. It helps a little that #%values is responsible for its own union and intersection operations, though.