Behaviour call syntax

[Theodus]

Please see #156 for prior discussion

Rendered

[SeanTAllen]

I discussed with Sylvan today. Some takeaways (many from Sylvan, a couple from me).

be is currently a subtype of fun tag.

To change the call site signature is to create a bifurcation in the type system. This would have a large impact on the codebase. You need two sets of subtyping to handle the bifurcation.

Essentially what the RFC is suggesting is to incorporate async/sync distinction into the type system. However, because async doesn't propogate up a call stack. It fails to achieve that end. This was brought up in discussions already as...

"well, I can have a fun I call sync and then it can just be wrapping an async be".

It isn't like when we introduced ? because errors do propagate so the change made sense and provided real benefit. Because async doesn't propagate, we'd be making the type system more complicated and not really achieving what I think is the real goal of the RFC (async/sync as part of type system).

Sylvan mentioned that a few years ago, early on in the Pony days, he built a stream handling library that allows you to switch dynamically between async or sync interactions because of the current type system and it was hugely valuable. He said he would try to find as one of our points of conversation was "we don't see value in this, because we haven't really seen be/fun tag relationship being used".

I think our goals are laudable, particularly, providing a better end user experience at the call site. However, i think that the trade-offs aren't worth it. I'm withdrawing my support from the RFC.

Sylvan is also against the RFC for the reasons above.

[Theodus]

I agree that a bifurcation of the type system around sync/async is not worth the benefit of the call site visibility.

[SeanTAllen]

I think we can address the problem with actors that take notifiers by being better about our APIs.

For any actor that takes a notifier we should:

have ever be call immediately into a corresponding fun. Then callers from within should be calling the fun to get sync behavior unless they specifically want async behavior with the be.

TCPConnection does a particularly bad job of this and is where most of the problems in the past have arisen.

[Theodus]

@SeanTAllen should that be translated into an issue for an RFC to improve APIs in that way?

[SeanTAllen]

@Theodus I think we need a review of the various notifier having actors in the standard library and see how they fair on this front. TCPConnection definitely needs improvement. That was one of the alternatives we discussed during some sync call when discussing the general issue.