Should `receive` evaluate (to WHNF or NF) the result of the callback?

[NicolasT]

Currently, the result of the callback passed to receive is written into an MVar as-is, for further consumption by another actor/thread.

If this value is not forced to WHNF or NF, this means the thread which performed the call may spend time/work to evaluate the value, which is counter-intuitive. Furthermore, if an (impure) exception is thrown during said evaluation, this would show up in the receiver, not in the actor that was called (let's not even consider what happens if the callback uses some withFoo internally and the resulting value depends on said Foo to still be "open").

Long story short, would it make sense to have a version of receive (maybe even receive itself) which evaluates the result of the callback (IMHO to NF by default) before "returning" it to the called?

[evanrelf]

You're right, and I agree 🙂 I would just change receive to the new behavior, no extra version.

[NicolasT]

So, I looked into this, but for now couldn't find a way to bring in an NFData constraint on res in forall res. msg res -> Actor msg res which could then later be used (within the implementation of receive) to deepseq(/rnf/force, whatever) said result. Since only callback knows anything about the concrete type of res given some msg, that seems to make sense.

So, not quite sure how to make this work at all, generically :thinking: Of course, one can deepseq at the end of the callback, but that leaves a lot of room for error.