> > I believe you imagine an actor simply demuxing or unzipping messages to > two or more other actors. But such a design does not result in the same > concurrency, consistency, or termination properties as a single actor, > which is why you cannot (correctly) treat the grouping as a single actor.
Well... composing multiple functions does not result in the same termination properties as a single function either, does it? Especially when we are composing nondeterministic computations? (real question, not rhetorical) I'm having difficulty seeing how this is unique to actors. > but it is my understanding that most actors languages and implementations > are developed with an assumption of ambient authority Well, yes, and it's a bad idea if you want object capability security. I implemented object capability security in a system that hosted JavaScript actors on Node.js. As long as you have a vm to interpret code in, you can control what it can and cannot access. I'm looking towards working on more lower level concepts in that direction. So far I've only addressed this problem from a distributed system perspective. I considered it (but haven't implemented it) from the language/operating system layer yet so I may be lacking a perspective that you already have. I'll know more in the future. You can thus speak of composing lambdas with functional composition, or > composing diagrams with graphics composition operations. But neither says > nothing at all about whether actors, or Kernel, or C or whatever they're > implemented in is composable. Composition is a property of abstractions. That's fair. You're right. But how do you weigh freedom to make choices for "the task at hand" even > if they're bad choices for the tasks NOT immediately at hand (such as > integration, maintenance)? For this, I think all of us fall back on heuristics as to what's a "good" idea. But those heuristics come from past experience. This ties back somewhat to what I mentioned about The Idea Flow method, and the difficulty of being able to determine some of those things ahead of time. My personal heuristic would argue that integration and maintenance should be of greater consideration. But I learned that by getting hit in the face with maintenance and integration problems. There are certainly approaches that are better than a random walk of choices, but which one of those approaches is best (Agile, XP, Lean, Lean Startup, Idea Flow Method, etc.) seems to still be an open question. At the low level of TCP/IP, there is no *generic* way to re-establish a > broken connection or recover from missing datagrams. Each application or > service has its own ad-hoc, inconsistent solution. The World Wide Web that > you might consider resilient is so primarily due to representational state > transfer (REST) styles and disciplines, which is effectively about giving > the finger to events. (Events involves communicating and effecting > *changes* in state, whereas REST involves communicating full > *representations* of state.) Also, by many metrics (dead links, behavior > under disruption, persistent inconsistency) neither the web nor the > internet is especially resilient (though it does degrade gracefully). Hmm. Based on your response, I think that we define event systems differently. I'm not saying I'm right, but it feels that I might be picking and choosing levels of abstraction where events occur. The system as a whole seems to me to be resilient, and I don't see that even if there is no generic way to re-establish connection at TCP/IP level this degrades resiliency somehow. Multiple layers are at play here, and they come together. No one layer would be successful by itself. I still think it's my communication failure at describing my view of the Internet, and not a lacking in the system itself. I'll have to do some more thinking on how to express it better to address what you've presented. People who focus on the latter often use phrases such as 'convergence', > 'stability', 'asymptotic', 'bounded error', 'eventual consistency'. It's > all very interesting. But it is historically a mistake to disregard > correctness then *handwave* about emergent properties; you really need a > mathematical justification even for weak correctness properties. > Biologically inspired models aren't always stable (there are all sorts of > predator-prey cycles, extinctions, etc.) and the transient stability we > observe is often anthropocentric. Agreed that disregarding correctness and *handwaving* emergent properties is a bad idea. It was more a comment on my starting state of mind to a problem than a rigorous approach to solving it. Although, stability is not necessarily the goal. Perhaps I'm more in the biomimetic camp than I think. On Sun, Apr 7, 2013 at 3:47 PM, David Barbour <[email protected]> wrote: > > On Sun, Apr 7, 2013 at 10:40 AM, Tristan Slominski < > [email protected]> wrote: >> >> >> Consider: You can't treat a group of two actors as a single actor. >> >> >> You can definitely group two actors as a single actor. It's almost >> trivial to do so. It requires creating another actor though :D. >> > > There are design patterns that can allow developers to treat a clusters of > collaborating actors as a single actor [1], but they are not trivial and > they require careful discipline and design of the whole cluster. > > I believe you imagine an actor simply demuxing or unzipping messages to > two or more other actors. But such a design does not result in the same > concurrency, consistency, or termination properties as a single actor, > which is why you cannot (correctly) treat the grouping as a single actor. > > [1] http://www.dalnefre.com/wp/2010/05/composing-actors/ > > > >> >> Also, you yourself, in "Life With Objects" mention object capability >> model. So to counter the statement of difficulty to reason about >> system-level properties, object capability model definitely makes it >> simpler to reason about the system-level property of security (by walking >> the actor "graph"). >> > > Object capabilities - and compositional reasoning about security > properties - are in my opinion the best contribution of OOP to CS. (Traits, > and Object Algebras, cf. William Cook's work [2], are up there, too.) I am, > of course, very interested in preserving this reasoning. But I'd also like > to address many other properties. > > [2] http://lambda-the-ultimate.org/node/4572 > > >> Correctly implemented actor systems (requirement is non-forgeable actor >> addresses) implement object capability model trivially. > > > Actors model is certainly capable of object capability patterns, but it is > my understanding that most actors languages and implementations are > developed with an assumption of ambient authority (i.e. the ability to > 'import' new capabilities, including stateful ones that would allow > indirect communication between actors). > > Developing a language with object capability constraints, or at least to > make it practical, requires special attention to modularity and > integration. It also requires reconsideration of many APIs where there must > be secure collaboration (e.g. for graphics, UI). This is, in mine and > others' experiences, not a trivial hurdle. > > > > As far as standard composition, I've seen lambda calculus implemented in >> actors, and I've seen actors implemented in Kernel >> > > Hmm. No, that doesn't count. You don't get to say "we can compose lambdas, > and we can implement lambdas with actors, therefore we can compose actors". > Such an argument, if accepted, would render composition meaningless. > > To recognize composition, you should identify three sets: the set of > compositional operands (components), the set of composition operators, and > the set of compositional properties. And there is a minimum of one > compositional property, which is algebraic closure (the result of > composition can be further composed). > > You can thus speak of composing lambdas with functional composition, or > composing diagrams with graphics composition operations. But neither says > nothing at all about whether actors, or Kernel, or C or whatever they're > implemented in is composable. Composition is a property of abstractions. > > We can, of course, create all sorts of ad-hoc abstractions, e.g. > frameworks or little-languages, that provide composition internally. A DSL > or framework might be much more composable than the language that > implements it. But so far the issue of integrating these solutions, e.g. of > composing frameworks, is poorly addressed. > > >> are you familiar with Storm ( https://github.com/nathanmarz/storm ) ? It >> is one example of composing things and providing guarantees at a slightly >> higher level of abstraction. >> > > Weakly familiar; I haven't used it, but I've seen the presentation and > know Storm implements event stream processing, which (as a model) is much > more composable than generic message passing (i.e. since you can model > external composition, topologies), but still leaves a lot to be desired. > > >> >> Much like my previous metaphor comments, it's important we get to pick >> and choose our metaphors for the task at hand. >> > > I'm always wary of such assertions. There are cases where choice is > important or necessary, of course. But how do you weigh freedom to make > choices for "the task at hand" even if they're bad choices for the tasks > NOT immediately at hand (such as integration, maintenance)? > > You use metaphors to inspire abstractions. Compositionality is a property > of, and therefore a constraint on, abstraction. There is some friction > here, though not a full contradiction (you can certainly find compositional > metaphors). > > >> there is always the one bright shining example of an event system that >> definitely counters, for example, your point that "Event systems lack >> generic resilience". As Alan likes to point out, the Internet was built by >> people. >> > > Eh, the internet is certainly NOT a counter-example to that point. > > At the low level of TCP/IP, there is no *generic* way to re-establish a > broken connection or recover from missing datagrams. Each application or > service has its own ad-hoc, inconsistent solution. The World Wide Web that > you might consider resilient is so primarily due to representational state > transfer (REST) styles and disciplines, which is effectively about giving > the finger to events. (Events involves communicating and effecting > *changes* in state, whereas REST involves communicating full > *representations* of state.) Also, by many metrics (dead links, behavior > under disruption, persistent inconsistency) neither the web nor the > internet is especially resilient (though it does degrade gracefully). > > > > So event systems can become powerful if we can get them right. >> > > Their power was never in question. Our ability to control and comprehend > that power, OTOH... > > >> >> Think of a read caching system. As long as it has the capacity, the more >> requests are executed, the more they are cached, the better the system >> response overall. That's an example of getting better in face of >> variability and demand. This followed by hot-spot detection, horizontal >> scaling in response, and load balancing across are all examples of a system >> improving when stressed. >> > > I agree, all of those are good adaptations. I tend to think of them in > terms of the properties that allow them, e.g. horizontal scaling is enabled > by idempotence and commutativity of certain operations, and similar for > caching. If one has machine learning support a constraint satisfaction > model, one gains both stability (we learn to find the same or near > solutions again and again) and performance (we find solutions more quickly). > > >> I often find myself deliberately disregarding "correctness", and thinking >> about how correctness can become an emergent property of the system. >> > > People who focus on the latter often use phrases such as 'convergence', > 'stability', 'asymptotic', 'bounded error', 'eventual consistency'. It's > all very interesting. But it is historically a mistake to disregard > correctness then *handwave* about emergent properties; you really need a > mathematical justification even for weak correctness properties. > Biologically inspired models aren't always stable (there are all sorts of > predator-prey cycles, extinctions, etc.) and the transient stability we > observe is often anthropocentric. > > >> Another inspiration for me in similar fashion was the Conscientious >> Software paper: >> >> http://pleiad.dcc.uchile.cl/_media/bic2007/papers/conscientioussoftwarecc.pdf >> > > I'll take a look. > > Regards, > > Dave > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
