pattern-matching/multimethod container

[Chris Gary]

Yes, multimethods have been done again and again.

I'm not sure if such a container exists, and I'm not claiming originality here, either.

I don't care for the lack of control available at runtime with static multimethods. I prefer to have explicit control over where and how pattern matching of this nature is to occur, and be able to isolate groups of these operations based on constructs that emerge only at runtime (e.g. available OpenGL extensions based on what the driver supports for a given display, supporting multiple different display adapters, etc...). There are, of course, hundreds of different ways to model something like that, I just found this pattern is the easiest to work with in that regard.

I've started an almost-skeleton implementation here: https://github.com/warp-10/caster

Opinions and random, but related wisdom are welcome, as the idea is still very rough.

Why a container? Above all other architectural smells, I despise hidden library allocations. Static multimethods would require a singleon-like allocator interface to control where new dispatch table entries are allocated. A container alleviates this issue by keeping allocations in one or a few well-defined places, and also eliminates the need for new syntax (unrelated callables can be used with the same dispatch mechanism without the need for consistency checking outside the container interface).

That said, if static multimethods were incorporated into the language, this library would still benefit from the required ABI changes.

[Chris Gary]

SHORT VERSION:

A type map that efficiently applies dynamic_cast to an input argument over a dynamic set of types.

Like "unordered_map<type_index, function<...>>", except that it handles lookup automatically and casts the input argument list to the best-fitting callable in the collection.

Great for:

• Extensible message passing, where the central "message" server need not expose any additional registration mechanism (no need for parallel meta-typing).
  
• Open-ended type mapping: Map things like an 'image<2, rgba>' to a handler that directs an implementation pointer to a 'GLImage<2, GL_RGBA>' allocation.
• Open-ended AST visitors: Extend an AST visitor at runtime to accept new node types without altering the visitor's definition.