Ah, yes, I had forgotten about nests and birds. IIRC, they're more like channels than promises, but channels can serve a similar purpose. So again, the idea seems to be to leave a token indicating where something should go, and a token indicating where it should be picked up?
Aside: I haven't explicated it here, but I believe it much better to avoid state embedded at the surface of the UI, for a lot of reasons (like persistence, disruption tolerance, simpler consistency properties, simpler undo or upgrade via history edits). Avoiding state can be achieved by makePromise if I use linear types. Negative or fractional types can do a similar job. A fractional type can model piping a time-varying signal through a promise. Best, Dave On Tue, Sep 10, 2013 at 10:35 PM, Darius Bacon <wit...@gmail.com> wrote: > 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 >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
