[bitc-dev] Retrospective: The Issues with Type Classes

[Pal-Kristian Engstad]

On 4/9/2012 10:28 AM, Jonathan S. Shapiro wrote:
> Huh? I don't think you are thinking this through. I write a library 
> function:
>
>    def faux-add(a, b) = { a + b }
>
> which is typed as
>
>   Arith 'a => 'a x 'a -> 'a
>
> and I put that in a library. I basically can't compile this function 
> at all until I know the instance of Arith, which isn't known until 
> dynamic compile time.

You have a choice. You either implement this library function as (poor 
C-syntax):

Value *FauxAdd(ArithRepr *tclass, Value *a, Value *b)
{
       return tclass->plus_func(a, b);
}

Which obviously is slow unless you perform some global optimizations at 
link stage.

The other option is to take your function as a C++ template, a cook-book 
for how to implement something. faux-add would not be a value (since it 
isn't a function), but it could be instantiated using a specific Arith 
instance.

You could probably even do both, but if you did I think people would 
like to be able to control it. For instance, you could use 'def 
function' and 'def generic' (or any other syntax to distinguish the cases).

PKE