4 ms·

Thanks for the link! I shall read it. I wrote a reply that is perhaps a bit too long to put here, so I put it at http://pastebin.com/4nN04Hj3 http://pastebin.c

by gruseom 13y ago

Thanks for the link! I shall read it. I wrote a reply that is perhaps a bit too long to put here, so I put it at http://pastebin.com/4nN04Hj3 http://pastebin.com/4nN04Hj3 instead. The short answers are: (1) this event loop is different from the browser's event loop because it's app-specific. Having a single interception point where you translate the browser event stream (mousedown, keypress etc.) into higher-level app-specific terms, and then write the rest of the UI in the latter, is a strategy for reducing complexity—an application of bottom-up programming to web UIs, really; and (2) emphatically yes, making the "official" event loop trivial and running all the complex stuff off your own app-specific loop allows you to control how much processing to do and when, which can be a way out of some thorny performance problems (such as sluggish scrolling) as well as an easy path to simulated concurrency. It's interesting that you should have said "drop/modify events superseded by subsequent ones" because that's precisely what led us to this design originally—we were desperate, in fact, for a way to do that. The bottom-up programming aspect and the concurrency aspect only became clear later.

abecedarius 13y ago
I think I read that E's promises came out of experience with UI programming too -- that they invented http://erights.org/elib/distrib/pipeline.html http://erights.org/elib/distrib/pipeline.html for the sake of sanely programming snappy UIs for Xanadu. Sounds like I gave up too easily on queuing and pruning events, or it was the particular platform (touch tracking on Nexus 7 and first-gen iPad). Thanks for the experience report. :-) It might help me remember this when I get back to http://wry.me/hacking/lissajous.html http://wry.me/hacking/lissajous.html to finish & polish -- I let it get all cut-and-pastey in doing drag-controls for the first time.
- gruseom 13y ago
  I've now read those pages. I knew about E for its capability model but not at all for its concurrency model, which is indeed very interesting (more interesting, to me) and close to home. There's a presentation mentioned there that I found slightly clearer than the page itself; the link is dead but it can be read here: http://web.archive.org/web/20070626045558/http://www.drjava.de/e-presentation/html-english/img0.html http://web.archive.org/web/20070626045558/http://www.drjava.... This model deserves to better known, especially since all this stuff is in play again nowadays. Are there other implementations of it? (Node.js might be a natural platform, given its event loop and the popularity of promises there.) I also wonder what the biggest differences are between it and Erlang. In your pipelining example (t3 := (x <- a()) <- c(y <- b())), what happens if the messages arrive out of order? (Or does the system prevent that and if so how?) I suppose if an expression can't be evaluated because a promise hasn't resolved yet, it could just go back to the end of the queue and eventually everything will bubble up? Also: that Xanadu? Wow, no idea. Edit: I forgot another thing I wanted to include in this omnibus comment. The paper "On the Development of Reactive Systems" that's mentioned at your first link and which can be found at [1], starts off with a very interesting and exciting distinction between "transformational" systems (which take inputs and transform them into outputs) and "reactive" systems that "are repeatedly prompted by the outside world and [whose] role is to continuously respond to external inputs. A reactive system, in general, does not compute or perform a function, but is supposed to maintain a certain ongoing relationship, so to speak, with its environment". I think this is extraordinarily lucid and that the authors are right to talk about concurrency—and probably complexity in general—in the latter sort of system as being a different challenge than in the former. Unfortunately, the paper quickly sinks into a pit of software process goo and never returns. A little Googling gives me the impression that important technical work did come out of it, though, and if anyone knows what the high points are I would like to see them. [1] http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/ReactiveSystems.pdf http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Reac...
  - abecedarius 13y ago
    Yes, that Xanadu! The VatTP protocol is meant to guarantee 'just enough' ordering as at http://www.erights.org/elib/concurrency/partial-order.html http://www.erights.org/elib/concurrency/partial-order.html -- there was a talk about VatTP, with slides, but I haven't seen a proper write-up and never learned it. I think http://ai.eecs.umich.edu/~tpkelly/Ken/ http://ai.eecs.umich.edu/~tpkelly/Ken/ is the most active descendant (and V8Ken linked from there which they intend to hook up with node.js). Daira Hopwood's new language Noether sounds promising: https://thestrangeloop.com/sessions/noether-a-concurrent-security-oriented-language https://thestrangeloop.com/sessions/noether-a-concurrent-sec... About Erlang, besides capabilities and mutable data I think the biggest difference comes from blocking receive. This gives it more of a CSP flavor. My own experience is limited -- my exposure to Erlang was mostly helping other hackers. (I also made an Erlang-influenced Scheme dialect I was unsatisfied with for boring reasons, but it was kind of in between: immutable data, channels as capabilities, synchronous messages.)

by gruseom 13y ago

abecedarius 13y ago

I think I read that E's promises came out of experience with UI programming too -- that they invented http://erights.org/elib/distrib/pipeline.html http://erights.org/elib/distrib/pipeline.html for the sake of sanely programming snappy UIs for Xanadu. Sounds like I gave up too easily on queuing and pruning events, or it was the particular platform (touch tracking on Nexus 7 and first-gen iPad). Thanks for the experience report. :-) It might help me remember this when I get back to http://wry.me/hacking/lissajous.html http://wry.me/hacking/lissajous.html to finish & polish -- I let it get all cut-and-pastey in doing drag-controls for the first time.

gruseom 13y ago
I've now read those pages. I knew about E for its capability model but not at all for its concurrency model, which is indeed very interesting (more interesting, to me) and close to home. There's a presentation mentioned there that I found slightly clearer than the page itself; the link is dead but it can be read here: http://web.archive.org/web/20070626045558/http://www.drjava.de/e-presentation/html-english/img0.html http://web.archive.org/web/20070626045558/http://www.drjava.... This model deserves to better known, especially since all this stuff is in play again nowadays. Are there other implementations of it? (Node.js might be a natural platform, given its event loop and the popularity of promises there.) I also wonder what the biggest differences are between it and Erlang. In your pipelining example (t3 := (x <- a()) <- c(y <- b())), what happens if the messages arrive out of order? (Or does the system prevent that and if so how?) I suppose if an expression can't be evaluated because a promise hasn't resolved yet, it could just go back to the end of the queue and eventually everything will bubble up? Also: that Xanadu? Wow, no idea. Edit: I forgot another thing I wanted to include in this omnibus comment. The paper "On the Development of Reactive Systems" that's mentioned at your first link and which can be found at [1], starts off with a very interesting and exciting distinction between "transformational" systems (which take inputs and transform them into outputs) and "reactive" systems that "are repeatedly prompted by the outside world and [whose] role is to continuously respond to external inputs. A reactive system, in general, does not compute or perform a function, but is supposed to maintain a certain ongoing relationship, so to speak, with its environment". I think this is extraordinarily lucid and that the authors are right to talk about concurrency—and probably complexity in general—in the latter sort of system as being a different challenge than in the former. Unfortunately, the paper quickly sinks into a pit of software process goo and never returns. A little Googling gives me the impression that important technical work did come out of it, though, and if anyone knows what the high points are I would like to see them. [1] http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/ReactiveSystems.pdf http://www.wisdom.weizmann.ac.il/~dharel/SCANNED.PAPERS/Reac...
- abecedarius 13y ago
  Yes, that Xanadu! The VatTP protocol is meant to guarantee 'just enough' ordering as at http://www.erights.org/elib/concurrency/partial-order.html http://www.erights.org/elib/concurrency/partial-order.html -- there was a talk about VatTP, with slides, but I haven't seen a proper write-up and never learned it. I think http://ai.eecs.umich.edu/~tpkelly/Ken/ http://ai.eecs.umich.edu/~tpkelly/Ken/ is the most active descendant (and V8Ken linked from there which they intend to hook up with node.js). Daira Hopwood's new language Noether sounds promising: https://thestrangeloop.com/sessions/noether-a-concurrent-security-oriented-language https://thestrangeloop.com/sessions/noether-a-concurrent-sec... About Erlang, besides capabilities and mutable data I think the biggest difference comes from blocking receive. This gives it more of a CSP flavor. My own experience is limited -- my exposure to Erlang was mostly helping other hackers. (I also made an Erlang-influenced Scheme dialect I was unsatisfied with for boring reasons, but it was kind of in between: immutable data, channels as capabilities, synchronous messages.)