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

Browse archivesActive forum topics 
Recent comments
22 hours 45 min ago
1 day 44 min ago
1 day 6 hours ago
1 day 23 hours ago
2 days 8 hours ago
2 days 19 hours ago
2 days 20 hours ago
2 days 20 hours ago
2 days 21 hours ago
2 days 21 hours ago