August 29th, 2012

beartato phd

(no subject)

Hmm. I wonder why we really need the generality of
ω2,ω1 τ = (τ → ω1) → ω2
as opposed to the answer-type-is-ω CPS monad
ω τ = (τ → ω) → ω

The latter seems to work, in that if I just forcibly unify all the //-annotations on the left with all the //-annotations on the right, things are still vaguely sensible. Is it just so we can treat the continuation-up-to-last-reset has having a kind of let-polymorphism?

For example, I seem to be able to type
"Hello World, today the temperature is " ^ (reset (shift k . Int.toString (k 25))

with a typing derivation sketched by:
k : int -> int |- Int.toString (k 25) : string
k : int -> int // string |- pure (Int.toString (k 25)) : string // string
// int |- shift k . pure (Int.toString (k 25)) : int // string
|- reset (shift k . pure (Int.toString (k 25)) : string
The moral here being that the "real" continuation that that shift captures is an evaluation context that is going to require a string, and yet since it's delimited, it's really only the identity function, and can be safely used at int.

And yet the effective let-polymorphism doesn't seem to be as complete as I might have expected, in that I have to choose the type of k once and for all when I shift, so that
(reset (shift k . (k "Hello ") ^ Int.toString (k 25))

does not appear to be well-typed.