andrewthad / accordion Goto Github PK

Currently, the ladder of types is something like:

• Field (keys usable in a record). There exists an isomorphism between Field and Vec Height Bool
• Universe (types considered distinct even if backed by the same haskell type, think about things like CustomerId and OrderId)
• Type (actual haskell types, here CustomerId and OrderId would both be backed by Int)

One thing I'm pondering is whether the library should require the isomorphism between Field and Vec Height Bool. Of course, any sane user would have the two be isomorphic, but should the library use this knowledge? There is only one place where it is currently required. If we got rid of this, Interpret would be of kind Vec Height Bool ~> Universe (using the UnsaturatedTypeFamilies notation, and the ladder would be:

• Field
• Vec Height Bool
• Universe
• Type

Field is really a convenience for users, but an important one since no user wants to be passing Finger Height v around. I think I will make this change.

The other idea is at the bottom of the ladder. What types will people typically want? Very common are going to be types like Int, Bool, and Text. I wonder if we could nail down a universe of common types (extensible via a type variable) so that libraries building on top of this could be sure to provide specialized implementations of functions for the right set of common types. Maybe something like:

data World a = WInt8 | WInt16 | WInt32 | WInt64 | WInt128 | WIntMach
  | WBool | WText ... 
  | WOther a

Users would define MyExtraTypes and then use World MyExtraTypes to get access to the full universe of types. Anything that fell under MyExtraTypes would get crummy boxed arrays and dictionary-passing for predicates, but the multi-data-constructor multi-field ADTs that end up handled this way are unlikely to see much benefit from specialized implementations of functions anyway.

I need to make sure that enum-style types (those with only nullary data constructors) get represented as Word8. Or at least that it's easy for users to tell the library that they want this behavior. We may actually need to go two different directions under universe to support this though. Something like:

                Field
                Vec Height Bool
                Universe
              /            \
            World           Type
            Type

To the right, we have the real type (e.g. CustomerId or an enum-style Weekday). To the left, we have the representations.

Note to self: World might need a dedicated enum data constructor for this to work. Maybe.