Hi,

This wasn't clear to me, as I haven't really followed this discussion. 
Would you mind explaining how bitc was to handle templated (generic) 
functions such as faux-add without using boxing/unboxing and passing 
hidden arguments to the generic function? Also, perhaps you could 
explain how you would deal with dynamic bitc libraries in this context?

Thanks,

PKE


On 4/9/2012 12:59 PM, Pal-Kristian Engstad wrote:
> 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
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to