I answered most of your other objections in a sibling comment, but to this:
> Nobody is attempting the actor model in Haskell because the actor model is anti static typing
People write servers in Haskell, no? Servers that speak to the internet? If so, they're writing actor-modelled programs; each actor is just an entire OS process.
Now, if you want to write several servers at once, and have them scheduled efficiently, you might want a DSL that allows you to write specify the code for several Haskell server processes, and also specify their relationships. Sounds like you're going to be writing some actor-modelled code!
Which is all to say, Haskell (and strongly-statically-typed FP et al) works perfectly fine as a language for specifying what goes on within an actor.
The actor boundary is precisely where the tradeoff between static typing and dynamic typing is made, because when you want to communicate between actors (where an actor may also represent a socket or somesuch), you have to stop speaking in terms of typed data, and start speaking in terms of pattern-matching on binary messages that a given version of an actor might not recognize the totality of.
Haskell could have actors. Erlang could have strong-typing within functions. Both languages would basically look like they're embedding the other by doing so. The right solution probably involves exactly the kind of mixing of semantics that that sounds like.
> Nobody is attempting the actor model in Haskell because the actor model is anti static typing
People write servers in Haskell, no? Servers that speak to the internet? If so, they're writing actor-modelled programs; each actor is just an entire OS process.
Now, if you want to write several servers at once, and have them scheduled efficiently, you might want a DSL that allows you to write specify the code for several Haskell server processes, and also specify their relationships. Sounds like you're going to be writing some actor-modelled code!
Which is all to say, Haskell (and strongly-statically-typed FP et al) works perfectly fine as a language for specifying what goes on within an actor.
The actor boundary is precisely where the tradeoff between static typing and dynamic typing is made, because when you want to communicate between actors (where an actor may also represent a socket or somesuch), you have to stop speaking in terms of typed data, and start speaking in terms of pattern-matching on binary messages that a given version of an actor might not recognize the totality of.
Haskell could have actors. Erlang could have strong-typing within functions. Both languages would basically look like they're embedding the other by doing so. The right solution probably involves exactly the kind of mixing of semantics that that sounds like.