[Haskell-cafe] Using type families to define runtime representation and evaluation strategy?

[Corey O'Connor]

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