Changes to supervision model

[srijs]

Hi!

I'm creating this issue to track the differences to the Erlang supervisor model, and get your opinion on what makes sense to get into this library as well.

Incomplete list of what the erlang supervisor does that this library doesn't:

• [ ] Supervisor shuts down on ChildRestartLimitReached (terminates all children, then itself)
• [ ] When a supervisor crashes, all its children are terminated before it is restarted
• [ ] By default, children are also restarted when they terminate unexceptionally (ChildFinished)
• [ ] There are three different kinds of children:
  • permanent, default, will always be restarted
  • transient, only restarted on exceptional failure
  • temporary, never restarted
• [ ] Children have an order in which they are started, and are shut down in reverse order

[adinapoli]

Hey @srijs , thanks for this nice list! It's great to have a detailed breakdown of what Erlang does without having to browse the OTP docs :wink:

I think we should aim to incorporate as many functionality as we can into the library, but with a twist. This is of course my personal, biased opinions!

My main feeling right now is that I don't want to turn this library into a fully-fledged, actor-semantic-based framework. What I mean by this is that of course (correct me if I'm wrong) the way supervisor trees works in Erlang is by making the assumption you are dealing with an actor model. In this context, it makes a great deal of sense always restarting the children even though the underlying computation finished unexceptionally, as it's implied those children carry an actor state and they need to be always available. It certainly might not be the case for the average Haskeller.

Said that, I'm not saying we shouldn't crack on and make all those changes! What I'm saying is that I would like to shape this library without the assumption the end user wants persistent children or even work with an actor model (thus we might, for example, start everything by default as transient, unless the user opts-in). The main reason I created this library in the first place was to offer a sort of forkIO on steroid, but without all the extra baggage coming from learning and understanding the supervision story.

So, in part, I would like to target 2 type of users:

• The guy which literally wants to write an extra one liner forkSupervised ... and be done, with the understanding forkSupervised works exactly as forkIO, but with the twist the computation is restarted in case of exceptional conditions.
• The Erlang refugee, which is the guy which expects to find the Erlang semantic in this library.

I think we can make both happy. What do you think?