I'm interested in the feasibility of extending the compiler using a construct similar to type synonym families to determine runtime representation and evaluation strategy for types. Can anybody point me to existing work in this area? I'm not sure of the exact terminology to be using here so my description is going to be fuzzy and probably off the mark on a few points. If anybody could help me clarify what I'm trying to described that would be appreciated. What I imagine is an open construct that be evaluated at compile time to determine: - How the data for a type is represented in memory. Whether values are boxed or unboxed etc. - How an expression should be represented. As a lazy evaluation thunk (weak head normal form?) or evaluated to normal form. - How a expression should be reduced. Since "the best" evaluation strategy depends on the application the equations should be open. For one application a data structure should be evaluated the normal form but not another. This is why the construct should be open much like type synonym families. One application could define an instance that declares the value should be reduced to HNF when defined while the other application could define an instance that declares the value to be reduced to WHNF. Still, the library implementor needs the ability to define reasonable defaults. If the construct was closed I don't think these requirements could be satisfied. This resembles extending the Control.Parallel.Strategies evaluation strategies and adaptive-container's container representation to be represented by type level equations. Control.Parallel.Strategies has a good interface but littering the equations with expressions declaring the evaluation strategy seems awkward. Preferably the evaluation strategy should be definable in parallel to the equations when possible. Strictness annotations already resemble the start of such a construct. And any such construct would have to be able to take the place of strictness annotations. Cheers, Corey O'Connor