Skip to content

Type-class-based dispatch #92

@iboB

Description

@iboB

Could we have type-class-based dispatch?

This would involve greatly expanding type classes.

Here's some ideas:

  • Link types and matching type classes
    • We could store matching types in type classes. The domain will have to update registered type classes when types change. This puts a burden on type creation but keeps types cleaner.
    • Alternatively types could have a list of matching type classes. This could make things easier on lookups, but becomes problematic when new type classes appear. Supporting this would mean that we might need to update "live" types, which is unpleasant and would involve locks.
      • Maybe only the type class list in a type could be lockable and all other features remain immutable (and lockless)
      • We could of course have an immutable type class list in a type, but that means new type classes (say, from a plugin) become much less versatile
    • In the end a bidirectional mapping may end up being desirable
  • Create type class vtables (dispatch tables)
    • Does it make sense to have type-class-level features (more than just function dispatch)
    • If we're pursuing multiple dispatch, perhaps they should be per function/feature rather than per type class

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions