On Wed, Sep 11, 2013 at 12:24 AM, David Barbour <dmbarb...@gmail.com> wrote: > One PL concept you didn't mention is promises/futures. How might those be > realized in a UI?
There's precedent: ToonTalk represents promises and resolvers in its UI as nests and birds. (Some reasons this may miss the mark: It's been many years since I played with ToonTalk; IIRC the system supports declarative concurrency and nothing more powerful; I don't understand you about negative and fractional types, though it sounds interesting: http://www.cs.indiana.edu/~sabry/papers/rational.pdf ) Darius > In the type system of a PL, promises can be modeled as a pair: > > makePromise :: 1 -> (resolver * future) > > Or we can potentially model promises using fractional or negative types, as > developed by Amr Sabry, which has an advantage of addressing sums in a > symmetric manner: > > receive :: 1 -> (1/a * a) > return :: (1/a * a) -> 1 > receive+ :: 0 -> (-a + a) > return+ :: (-a + a) -> 0 > > But what would this look like in a UI model? My intuition is leaving some > sort of IOU where a value is needed then going to some other location to > provide it (perhaps after a copy and a few transforms). I suspect this > behavior might be convenient for a user, but it potentially leaves parts of > the UI or system in an indefinite limbo state while a promise is unfulfilled. > Though, perhaps that could be addressed by requiring the promises to be > fulfilled before operations will 'commit' (i.e. enforcing type-safe UI > transactions). _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
