The types are dynamically mixed-in to the object. Since it’s done at runtime there aren’t any guarantees that the object has the particular feature you’re requesting, though you can look for it ahead of time. The idea is that this could form a loose interface between actors, who only require that the objects sent to them obey certain sub-requirements.

One of the ideas of using the dynamic mix-in as opposed to all statics or subtyping, was the idea that objects could be “souped up” to meet requirements of particular actors. If you had an Item, but your shopping cart actor required a Label and a Price, you could meld those onto the object at runtime, and prevent any structural bloat in the class definition for Item. This would allow you to reuse your Item in a different context that wasn’t shopping cart-related.

In Minnow there is no shared state. The finished language will allow you to chose between a scope-enforced pass-by-handoff, or simply by copying what you wish to send.

Monads, too, have a problem in that they aren’t concurrent. By definition they define a string of things that must be done in order.

Instead, what is more helpful is to talk about the system as connected autonomous actors, so that you can use analysis to see how best to lay these actors on the hardware (you can see my Minnow talk for a light introduction, or dive into the StreamIT papers for more information)

The finished Minnow will allow higher order automation.

Aside from treating actors like sort-of monads, does Minnow actually support higher-order constructs? If it does, then I suppose it would be possible to avoid mutable state for the most part, it would just take a bit of self-control.