what are OTP ideas that probably aren't a good fit?

[cartazio]

(i'm super green / known nothing on the erlang & OTP side, and that'd be handy for understanding and looking at the OTP libs for ideas)

[hyperthunk]

Yes I totally agree. The main thing we need to get right to start with IMO is the supervisor concept. Once we've figured that out then a lot of the good stuff in OTP is about making it easy to write a process that deals with your application logic only, but can participate in a supervision tree in a well behaved fashion.

I suspect the primary area where our approaches will differ significantly from Erlang is that of behaviours - see the OTP Design Principles documentation for an overview.

Many key features in OTP are built on the idea of a 'behavior' - perhaps best known is the gen_server, which implements a kind of generic client/server mechanism where the user supplies a callback module to deal with various incoming messages.

There's not really anything analogous to this in Haskell, apart from session types perhaps, which are probably a bit too complicated to be useful at this stage. Whilst the gen_server concept makes a good attempt at abstracting some of the non-functional parts of the client server relationship away, it does little to support defining a contract between the two which goes beyond dealing with concurrency and the server life-cycle. Segregating the interface proper (as supported by the handle_{call, cast} from direct receipt (in handle_info) for example is quite useful, as is the provision of a standardised start and stop phase. But it all relies heavily on the fact that user supplied callback functions (which implement the 'functional aspects' of the process) can take any data, what with Erlang being dynamically typed.

So, the challenge would be to think about what types the gen server interface would provide. But I'm not even convinced this concept is hugely useful to us in Cloud Haskell. I suspect we'd be better off stealing the idea of a generic process that deals with a few non-functionals, such as

• handling the reply channel used to communicate with clients
• handling sync versus async traffic
• handling the start up
• handling the shut down
• dealing with system messages (i.e., for debugging purposes)

If we were to couple these with a nice API that hides the details from client code as well, then that would probably be quite useful. And furthermore I don't think it's nice that every call site wishing to interact with a 'generic process' should have to be pulled up into the Process monad and/or become a process itself. So having an API that allows you to spawn off a process and them provide a data exchange mechanism to unwrap return values would be very useful too IMO.

I also think that we should look at providing a generic process that handles certain pre-defined (of user configurable) process interactions, such as

• request/reply channels
• process pools
• work stealing

and so on.