{"action":"created","issue":{"url":"https://api.github.com/repos/vanrein/perpetuum/issues/1","repository_url":"https://api.github.com/repos/vanrein/perpetuum","labels_url":"https://api.github.com/repos/vanrein/perpetuum/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/vanrein/perpetuum/issues/1/comments","events_url":"https://api.github.com/repos/vanrein/perpetuum/issues/1/events","html_url":"https://github.com/vanrein/perpetuum/issues/1","id":205408593,"number":1,"title":"Find a model for Backend Driving","user":{"login":"vanrein","id":1358341,"avatar_url":"https://avatars.githubusercontent.com/u/1358341?v=3","gravatar_id":"","url":"https://api.github.com/users/vanrein","html_url":"https://github.com/vanrein","followers_url":"https://api.github.com/users/vanrein/followers","following_url":"https://api.github.com/users/vanrein/following{/other_user}","gists_url":"https://api.github.com/users/vanrein/gists{/gist_id}","starred_url":"https://api.github.com/users/vanrein/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vanrein/subscriptions","organizations_url":"https://api.github.com/users/vanrein/orgs","repos_url":"https://api.github.com/users/vanrein/repos","events_url":"https://api.github.com/users/vanrein/events{/privacy}","received_events_url":"https://api.github.com/users/vanrein/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2017-02-05T07:43:05Z","updated_at":"2017-02-05T09:52:17Z","closed_at":null,"body":"We have considered a few models up to here:\r\n\r\n**Request/Response.**  This is where Rick's idea for Perpetuum came from, as a model of asynchronous processing, cutting long-lasting (remote) requests into a request/response pair and treating each of these atomically on a transition.  Requests would be outgoing actions, responses would be incoming events (and probably extend the logic of a surrounding event loop).\r\n\r\n**Longer Activities in Places.**  This addition by Adriaan meant that we did not have to explicitly write down requests and responses.  We could make the following transitions dependent on the exit code or another form of return value, perhaps the `errno` variable, to accommodate more flow control.\r\n\r\n**Multiple outputs.** One longer-lasting process could bring out more than one output.  A good application would be an LDAP query that responds with any number of `SearchResult` messages before it sends `SearchDone`.  It is attractive to be able to process the individual `SearchResult` messages separately, so their contents can more easily be dissiminated over the rest of the graph.  This was not possible with a transition looping back to the place holding the long-lasting activity, but we needed that to retain the Petri net semantics that supports analysis.  So we had to explicitly start the long-lasting activity before the place."},"comment":{"url":"https://api.github.com/repos/vanrein/perpetuum/issues/comments/277508103","html_url":"https://github.com/vanrein/perpetuum/issues/1#issuecomment-277508103","issue_url":"https://api.github.com/repos/vanrein/perpetuum/issues/1","id":277508103,"user":{"login":"vanrein","id":1358341,"avatar_url":"https://avatars.githubusercontent.com/u/1358341?v=3","gravatar_id":"","url":"https://api.github.com/users/vanrein","html_url":"https://github.com/vanrein","followers_url":"https://api.github.com/users/vanrein/followers","following_url":"https://api.github.com/users/vanrein/following{/other_user}","gists_url":"https://api.github.com/users/vanrein/gists{/gist_id}","starred_url":"https://api.github.com/users/vanrein/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vanrein/subscriptions","organizations_url":"https://api.github.com/users/vanrein/orgs","repos_url":"https://api.github.com/users/vanrein/repos","events_url":"https://api.github.com/users/vanrein/events{/privacy}","received_events_url":"https://api.github.com/users/vanrein/received_events","type":"User","site_admin":false},"created_at":"2017-02-05T09:52:17Z","updated_at":"2017-02-05T09:52:17Z","body":"An excellent discussion of [structured types and the semantics of pattern matching](http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/PAGES/051.HTM) and [efficient compilation of pattern matching](http://research.microsoft.com/en-us/um/people/simonpj/papers/slpj-book-1987/PAGES/078.HTM) can be found in the excellent book on Implementation of Functional Programming Languages by Simon Peyton-Jones.\r\n\r\nOther than provindng an elegant encoding mechanism, this also demonstrates how completeness can be verified.  This helps to avoid that the backend may wish to communicate something that the front-end isn't picking up.  So if we create typing of similar structure (basically [sum and product types](http://charlieharvey.org.uk/page/sum_and_product_types), so nothing fancy) we should be able to report if the user forgets a branch and thereby risks deadlocks that the Petri net analysis might have missed.\r\n\r\nThere are good reasons to describe backends as Petri nets themselves, though, and then this line of analysis would end up with the general Petri net analysis.  Still, the completeness of structure matching at the various splits in a Petri net's flow could be valuable, even just as a hint that these backend models would add something useful (in case their inclusion during analysis is made optional)."}}
{"actor":{"display_login":"vanrein"}}