On Thu, Feb 12, 2015 at 1:41 AM, William ML Leslie <[email protected]> wrote: > On 12 February 2015 at 20:30, Matt Rice <[email protected]> wrote: >> >> On Thu, Feb 12, 2015 at 12:46 AM, William ML Leslie >> <[email protected]> wrote: >> > On 12 February 2015 at 19:27, Matt Oliveri <[email protected]> wrote: >> >> >> >> I'm not sure what you're saying we should infer for the (f x y) >> >> example. That could either be a 2-application, or two 1-applications, >> >> if they had the same syntax. That's why I proposed writing two >> >> 1-applications like ((f x) y). >> > >> > >> > Calling convention is a property of a value (of f), rather than of an >> > application. A value supports one native arity, although it can be >> > converted to another. >> >> I haven't really caught up on this thread, but I find this statement >> rather weird, in that sometimes we know the type of a value without >> knowing the value itself until somewhere down the partial evaluation >> process... in this cases we generate a dummy placeholder value where >> the dummy and the actual value have the same type, and it appears >> like there is a reading of this where the dummy, and the actual value >> need not share a calling convention? > > > Ok. So what calling convention does this dummy support? Or is it not > directly callable?
It depends really, for instance in the thing I linked in my previous email http://cap-lore.com/Languages/Synergy/OCaml.html 'nullObj' can be considered the placeholder, the value of 'obj' is not known until 'seal' is called, but that its type is equivalent to 'nullObj' is known, so it depends entirely on the caller, in other cases a similar function may call into 'obj' or dummy object or both, if obj needs to be directly callable so should the dummy, but there is no need for it to produce anything worthwhile, it may just be there to tie the type inference together. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
