On 13 August 2010 02:43, Jonathan S. Shapiro <[email protected]> wrote:
> On Wed, Aug 11, 2010 at 11:20 PM, William Leslie
> <[email protected]> wrote:
>>
>> On 12 August 2010 15:22, Jonathan S. Shapiro <[email protected]> wrote:
>> > Does this smell like it might work? If so, then the whole thing becomes
>> > purely a matter of surface syntax.
>>
>> Sure. Can I still specify a concrete calling convention for a
>> parameter or field? Do I need to specify the calling convention of
>> exported functions? If not, what is the default?
>
>
> I don't understand the question. The calling convention is defined by the
> underlying platform. The proposed rule is that given a chain of arrows, the
> right-most thing is the return value. If the return value is a function, it
> must be parenthesized.
I mean that if I have a struct field or function argument which
accepts functions of both conventions (fn 'a 'b -> 'c) and (fn 'a ->
'b -> 'c), which type will they ultimately be emitted as? In the
following example, can I expect a naieve runtime to exhaust the heap
generating wrappers for the function? Is foo.native always emitted as
the equivalent "int foo(int x, int y)" in C would be? In other words,
when does the conversion actually happen?
mutable struct Foo<'a, 'b, 'c> {
native :: fn 'a 'b -> 'c
currying :: fn 'a -> 'b -> 'c
}
f x y = x << 1 ^ y :: Int -> Int -> Int
swap_forever(z :: Int, foo :: Foo) :: Int {
foo.currying = foo.native
foo.native = foo.currying
swap_forever( (foo.native z z) foo)
}
swap_forever 0 foo (Foo f f)
--
William Leslie
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
