[bitc-dev] Arity: middle position?

William Leslie william.leslie.ttg at gmail.com
Thu Aug 12 18:11:40 PDT 2010

On 13 August 2010 02:43, Jonathan S. Shapiro <shap at eros-os.org> wrote:
> On Wed, Aug 11, 2010 at 11:20 PM, William Leslie
> <william.leslie.ttg at gmail.com> wrote:
>> On 12 August 2010 15:22, Jonathan S. Shapiro <shap at eros-os.org> 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

More information about the bitc-dev mailing list