4 ms·

That could be much better solved through coeffects, but unfortunately most languages don’t support that. Doesn’t mean using async functions is a good way for th

by phyrex 2y ago

That could be much better solved through coeffects, but unfortunately most languages don’t support that. Doesn’t mean using async functions is a good way for this either

throwitaway1123 2y ago
> That could be much better solved through coeffects It's possible, but I can't thoroughly evaluate coeffects until they land in a mainstream language with production usage. What I do know from experience is that you can't quietly block the entire thread on a network request in some innocuous looking function in JS. You have to return a promise and then the calling function has the option to await that promise, but I'm sure the academics in their ivory towers have theorized about something better.
- phyrex 2y ago
  It doesn't quite fit your requirements, but Facebook's PHP variant has an effects system like that which they use: https://docs.hhvm.com/hack/contexts-and-capabilities/introduction https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...
  - throwitaway1123 2y ago
    This looks pretty cool. One issue I have from just a cursory glance is that the IO capability includes things like `print` and `echo` [1]. If the context system can't differentiate between `console.log` and `fetch`, then it's a little less useful for me. If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2]. [1] https://docs.hhvm.com/hack/contexts-and-capabilities/available-contexts-and-capabilities#capabilities__io https://docs.hhvm.com/hack/contexts-and-capabilities/availab... [2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/HIPs/contexts_and_coeffects.md#runtime-semantics-of-co-effects https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...
    - phyrex 2y ago
      Hack is custom made for facebook and its use cases, and there’s no use for distinguishing those kind of IO at Facebook. The main use case for the effects system is actually privacy, wherein where processes that aren’t privacy controlled cannot access user data or data that got processed by other functions that did. And that’s enforced by the runtime. It’s super cool and a great example of what those systems are capable of.

by phyrex 2y ago

That could be much better solved through coeffects, but unfortunately most languages don’t support that. Doesn’t mean using async functions is a good way for this either

throwitaway1123 2y ago

> That could be much better solved through coeffects It's possible, but I can't thoroughly evaluate coeffects until they land in a mainstream language with production usage. What I do know from experience is that you can't quietly block the entire thread on a network request in some innocuous looking function in JS. You have to return a promise and then the calling function has the option to await that promise, but I'm sure the academics in their ivory towers have theorized about something better.

phyrex 2y ago
It doesn't quite fit your requirements, but Facebook's PHP variant has an effects system like that which they use: https://docs.hhvm.com/hack/contexts-and-capabilities/introduction https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...
- throwitaway1123 2y ago
  This looks pretty cool. One issue I have from just a cursory glance is that the IO capability includes things like `print` and `echo` [1]. If the context system can't differentiate between `console.log` and `fetch`, then it's a little less useful for me. If there was a way for users to define their own coeffects then you could sidestep this issue, but I saw this quote in one of the design documents: "Runtime will have a native knowledge of each co-effect. We will not allow co-effects to be defined in user-land code [...] An important aspect to note here is that certain co-effects that need deep support from runtime such as io and pure will need to be implemented in the runtime" [2]. [1] https://docs.hhvm.com/hack/contexts-and-capabilities/available-contexts-and-capabilities#capabilities__io https://docs.hhvm.com/hack/contexts-and-capabilities/availab... [2] https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/HIPs/contexts_and_coeffects.md#runtime-semantics-of-co-effects https://github.com/facebook/hhvm/blob/master/hphp/hack/doc/H...
  - phyrex 2y ago
    Hack is custom made for facebook and its use cases, and there’s no use for distinguishing those kind of IO at Facebook. The main use case for the effects system is actually privacy, wherein where processes that aren’t privacy controlled cannot access user data or data that got processed by other functions that did. And that’s enforced by the runtime. It’s super cool and a great example of what those systems are capable of.