`raise` should not be a blocking operation about purescript-halogen

[garyb]

I think the case you're exploring there is a little different from how this was experienced.

I'm saying a child disappearing killed the current eval in the parent component. I agree that a child being removed should terminate any actions it is taking, I don't agree that it should also kill the eval that performed the removal when that eval arose from the child raising a message.

That doesn't seem like "cancelling a child's pending actions", since we're in the context of the parent at this point.

[garyb]

I've found another issue related to this: if you're handling the message from a child, and within that eval you modify the state in such a way that the child is removed, it will immediately terminate the eval after the state change. So:

HandleChildMessage _ -> do
  traceM "Hello"
  H.modify_ removeTheChildThatRaisedThisMessage
  traceM "Goodbye"

The traceM "Goodbye" is unreachable here.

[natefaubion]

I think that case is reasonable, where removing a child is equivalent to cancelling the child's pending actions. That is, it's equivalent to sending a kill to all fork ids, which is certainly a thing Halogen already exposes as part of it's API. I think that if you needed guarantees around uncancellable blocks of HalogenM, you'd need to provide an API for that (such as invincible).

[thomashoneyman]

I think that case is reasonable, where removing a child is equivalent to cancelling the child's pending actions. That is, it's equivalent to sending a kill to all fork ids, which is certainly a thing Halogen already exposes as part of it's API. I think that if you needed guarantees around uncancellable blocks of HalogenM, you'd need to provide an API for that (such as invincible).

That's not what I would intuitively expect; the child notified the parent of a message, but that doesn't mean the parent will necessarily react by interacting with the child further.

As an analogy, if I am handling a click event in the DOM, I wouldn't expect my handler to get cancelled halfway through because the element that was clicked was removed in the meantime (though I would expect that attempting to interact with that element would now fail, the same way that H.query will fail if the indicated child component has been removed)

[natefaubion]

But DOM handlers are synchronous and linear. Code in HalogenM is asynchronous and concurrent (regardless of what your m is), so it requires concurrency semantics.

[natefaubion]

Perhaps another way of phrasing it:

someHalogenM = do
  raise ...
  lift $ Console.log "Hello"

eval = do
  SomeAction ->
    someHalogenM
  AnotherAction ->
    void $ H.fork someHalogenM

What happens here? There are a few possibilities:

• SomeAction continues execution because it's a "root eval" (ie not forked by the user), AnotherAction gets cancelled because it s a fork.
• They both continue execution because removing a child never invokes a cancellation of component fibers. This leads to pervasive leaks because you can never run potentially infinite async loops.
• They are both cancelled because the runtime treats managed forks (those forked by the runtime) identically to user forks.

To me, the third option is the only composable behavior since it's uniform. The first gives you observable differences in behavior, and IMO is non-composable since every root action gets the equivalent to an implicit invincible. This means if you ever run an async loop of some kind, you need to remember to fork it or it will always leak.

The concurrency semantics of Aff (which Halogen piggy backs on) are such that everything is cancellable by default. If things should not be cancellable, then they need to be invoked through explicit regions (bracket, invincible, etc). I personally don't consider runtime managed forks to be an explicit region.

[natefaubion]

Oh, I see. I misunderstood the example. I should have read closer. Yes, I agree with you that a child disappearing should not result in the parent halting execution.

It sounds like the parent execution is being run within the context of the child's fiber execution.

[garyb]

Yeah, I'm pretty sure that's exactly the problem. 👍

It's a confusing example 😄