4 ms·

In Logic Programming, Actors continue processing. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114 https://papers.ssrn.com/sol3/

In Logic Programming, Actors continue processing. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114

triska 7y ago
One very interesting development in this direction is Web Prolog by Torbjörn Lager: https://github.com/Web-Prolog/swi-web-prolog/raw/master/book/web-prolog.pdf https://github.com/Web-Prolog/swi-web-prolog/raw/master/book... Quoting from the introduction: "In particular, we pick the features that make Erlang into an actor programming language, and on top of these we define the concept of a pengine – a programming abstraction in the form of a special kind of actor which closely mirrors the behaviour of a Prolog top-level." And quoting from Section 1.3 of the current draft: "Is the actor programming model compatible with the logic programming model, and does the combination of the two models make sense? Yes, we will try to show that the actor programming model of Web Prolog is able to co-exist harmoniously with its logic programming model, and that both models are usable in the same program, with actors used for modelling the reactive, deterministic interfaces to the user and other external entities, and with the non-deterministic component behaving as an actor, encapsulating the non-determinism." Chapter 3 cites your work directly: "Actors, as specified in (Hewitt et al., 1973), involve entities that have their own mailbox."
- ProfHewitt 7y ago
  Unfortunately, Actors cannot be efficiently implemented in browsers because of the way that they implement concurrency.
  - 7thaccount 7y ago
    When you say "they", I assume you mean "browsers"? Sorry for the dumb question. I know precious little about web programming and concurrency.
    - Izkata 7y ago
      Except for webworkers (relatively new, I've not used them and know little about them), javascript in browsers is single-threaded. Even asynchronous things like ajax requests can only handle the result once the thread finishes doing whatever it was doing.
      - 7thaccount 7y ago
        Interesting and thanks for the explanation. Does it have to be single threaded?
        ProfHewitt 7y ago
        JavaScript in browsers was decreed by the standards committee to be single-threaded forever. Consequently, JavaScript is entirely lacking in concurrency constructs, e.g., implementing a region of mutual exclusion inside a JavaScript program.
        7thaccount 7y ago
        Thanks! I assume that was for a reason? Or just oversight?
  - bitwalker 7y ago
    I’m not sure I agree. For example, nothing about Erlang makes it unsuitable for a browser environment, it can handle running single threaded, or distributed across workers, where each worker runs its own scheduler. The only limitation is interacting with the DOM, since that must all happen in the main thread, but it is still possible to treat that the same way other blocking I/O is dealt with in the scheduler. I’m actually working on a compiler/runtime for Erlang for WebAssembly, so I’m maybe more familiar than most with how it works in practice.
    - ProfHewitt 7y ago
      Workers can be made to work in a browser, but communication can be awkward and slow.
      - monoideism 7y ago
        > Workers can be made to work in a browser, but communication can be awkward and slow. True, but with the SharedMemory browser API, things are looking up (but not yet implemented in all major browsers).
      - bitwalker 7y ago
        Apologies, Professor, I missed your reply! SharedArrayBuffer makes communication between schedulers essentially equivalent to non-browser environments, but support for it is still iffy at best due to Spectre. Luckily, that is a temporary problem, not a fundamental issue (SharedArrayBuffer being disabled that is, not Spectre). In a single-threaded setting, there isn't any significant overhead that I'm aware of between a browser and non-browser environment, aside from any overhead potentially incurred by executing on the WebAssembly VM rather than directly on the host machine. Of course, running single-threaded is less than ideal for other reasons.

In Logic Programming, Actors continue processing. See the following: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114 https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3428114

triska 7y ago

One very interesting development in this direction is Web Prolog by Torbjörn Lager: https://github.com/Web-Prolog/swi-web-prolog/raw/master/book/web-prolog.pdf https://github.com/Web-Prolog/swi-web-prolog/raw/master/book... Quoting from the introduction: "In particular, we pick the features that make Erlang into an actor programming language, and on top of these we define the concept of a pengine – a programming abstraction in the form of a special kind of actor which closely mirrors the behaviour of a Prolog top-level." And quoting from Section 1.3 of the current draft: "Is the actor programming model compatible with the logic programming model, and does the combination of the two models make sense? Yes, we will try to show that the actor programming model of Web Prolog is able to co-exist harmoniously with its logic programming model, and that both models are usable in the same program, with actors used for modelling the reactive, deterministic interfaces to the user and other external entities, and with the non-deterministic component behaving as an actor, encapsulating the non-determinism." Chapter 3 cites your work directly: "Actors, as specified in (Hewitt et al., 1973), involve entities that have their own mailbox."

ProfHewitt 7y ago
Unfortunately, Actors cannot be efficiently implemented in browsers because of the way that they implement concurrency.
- 7thaccount 7y ago
  When you say "they", I assume you mean "browsers"? Sorry for the dumb question. I know precious little about web programming and concurrency.
  - Izkata 7y ago
    Except for webworkers (relatively new, I've not used them and know little about them), javascript in browsers is single-threaded. Even asynchronous things like ajax requests can only handle the result once the thread finishes doing whatever it was doing.
    - 7thaccount 7y ago
      Interesting and thanks for the explanation. Does it have to be single threaded?
      - ProfHewitt 7y ago
        JavaScript in browsers was decreed by the standards committee to be single-threaded forever. Consequently, JavaScript is entirely lacking in concurrency constructs, e.g., implementing a region of mutual exclusion inside a JavaScript program.
        7thaccount 7y ago
        Thanks! I assume that was for a reason? Or just oversight?
- bitwalker 7y ago
  I’m not sure I agree. For example, nothing about Erlang makes it unsuitable for a browser environment, it can handle running single threaded, or distributed across workers, where each worker runs its own scheduler. The only limitation is interacting with the DOM, since that must all happen in the main thread, but it is still possible to treat that the same way other blocking I/O is dealt with in the scheduler. I’m actually working on a compiler/runtime for Erlang for WebAssembly, so I’m maybe more familiar than most with how it works in practice.
  - ProfHewitt 7y ago
    Workers can be made to work in a browser, but communication can be awkward and slow.
    - monoideism 7y ago
      > Workers can be made to work in a browser, but communication can be awkward and slow. True, but with the SharedMemory browser API, things are looking up (but not yet implemented in all major browsers).
    - bitwalker 7y ago
      Apologies, Professor, I missed your reply! SharedArrayBuffer makes communication between schedulers essentially equivalent to non-browser environments, but support for it is still iffy at best due to Spectre. Luckily, that is a temporary problem, not a fundamental issue (SharedArrayBuffer being disabled that is, not Spectre). In a single-threaded setting, there isn't any significant overhead that I'm aware of between a browser and non-browser environment, aside from any overhead potentially incurred by executing on the WebAssembly VM rather than directly on the host machine. Of course, running single-threaded is less than ideal for other reasons.