On 25 February 2015 at 22:53, William ML Leslie < [email protected]> wrote:
> On 26 February 2015 at 09:01, Keean Schupke <[email protected]> wrote: > Native arity itself is statically resolvable in Keenan's scheme exactly > where it is needed: where the call operation is. No templating involved, > which is a nice feature. > > -- > William Leslie > So I am trying to work out how to get the type inference to follow the cases where the compiler will be able to do this transformation statically. This is a simple example I am looking at. "random" is a boolean that is nondeterministically true or false at runtime preventing static determination: def f = \x y . x + y def g = \x y . x - y def j = \k . (k 1) let h = if (random) then f else g in j h 2 It seems knowing the concrete type at the site of application works for applying a more-curried function to where a less-curried one is expected, but has problems with the other way around. It seems that knowing the concrete types of all applications of a function at the definition site would allow all the specialisations required to be generated, in precisely the cases necessary. So I need to change my implementation to not do the subtyping-test at the application site, but the definition site. I am also going to see if I can actually transform the AST and re-infer the type, which should prove soundness as after the transform we should be dealing with only concrete arities and no subtyping. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
