User loginNavigation 
Compositional let bindingsI have been working on compositional let bindings, and wanted to get some comments on what I have so far. Each program fragment is typed with a monomorphic input context (the free variable requirements for the fragment) and an output polymorphic context (the definitions exported from the fragment). Lambda abstraction works as before, removing a variable from the inputcontext of the rhs. Let is more interesting, it adds the defined variable to the outputcontext, but we also want it to be usable in expressions. My first attempt is to have the let binding act as the identity function, so that apply does the necessary substitutions (symmetrically) from definitions in one fragment to requirements in the other. This is what a typing derivation looks like: (x = \z . (z, z)) (x 1, x true) 1. [var] {z : a}  z : a 2. [var] {z : a}  z : a 3. [prd (1) (2)] {z : a, z : b}  (z, z) : (a * b) 4. [abs z (3)]  (\z . (z, z)) : (a > (a * a)) 5. [let x (4)]  { x : (a > (a * a))} (x = (\z . (z, z))) : (b > b) 6. [var] {x : a}  x : a 7. [lit]  1 : Int 8. [app (6) (7)] {x : (Int > a)}  (x 1) : a 9. [var] {x : a}  x : a 10. [var]  true : Bool 11. [app (9) (10)] {x : (Bool > a)}  (x true) : a 12. [prd (8) (11)] {x : (Int > a), x : (Bool > b)}  ((x 1), (x true)) : (a * b) 13. [app (5) (12)]  { x : (a > (a * a))} ((x = (\z . (z, z))) ((x 1), (x true))) : ((Int * Int) * (Bool * Bool)) Does this approach seem reasonable? It seems that I can implement all sorts of weird scoping rules, as the definitions compose upwards, which is probably not desirable but can be fixed by clearing the polymorphic output context where appropriate. By Keean Schupke at 20140618 09:26  LtU Forum  previous forum topic  next forum topic  other blogs  12392 reads

Browse archives
Active forum topics 
Recent comments
6 days 2 min ago
6 days 3 min ago
1 week 4 days ago
2 weeks 1 day ago
2 weeks 1 day ago
2 weeks 2 days ago
2 weeks 2 days ago
4 weeks 3 days ago
7 weeks 6 days ago
8 weeks 5 hours ago