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  9686 reads

Browse archivesActive forum topics 
Recent comments
2 hours 34 min ago
2 hours 57 min ago
3 hours 16 min ago
5 hours 44 min ago
16 hours 6 min ago
18 hours 3 min ago
1 day 1 hour ago
1 day 1 hour ago
1 day 2 hours ago
1 day 2 hours ago