2 ms·

I'm really interested in the topics discussed in this article. My new Haskell effect system, Bluefin[1], is based on this idea of "contexts" (which Bluefin cal

by tome 3y ago

I'm really interested in the topics discussed in this article. My new Haskell effect system, Bluefin[1], is based on this idea of "contexts" (which Bluefin calls "handles"). Bluefin explicitly passes handles. There's another effect system called effectful[2] which does the implicit version. I prefer the implicit version and disagree with the claim in the article that it will lead to dozens of arguments. What we normally do when we have dozens of things that belong together is that we package them all up into data structures/records/objects that group related functionality. I expect that approach to be applicable to passing contexts too. [1] https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin [2] https://hackage.haskell.org/package/effectful https://hackage.haskell.org/package/effectful

lioeters 3y ago
> I prefer the implicit version From the context (hehe) I think you meant you prefer the explicit version? Personally I'd prefer to make things explicit, even if it's more verbose. > Bluefin is a Haskell effect system with a new style of API. > It is distinct from prior effect systems because effects are accessed explicitly through value-level handles which occur as arguments to effectful operations. https://github.com/tomjaguarpaw/bluefin/blob/master/bluefin/src/Bluefin.hs https://github.com/tomjaguarpaw/bluefin/blob/master/bluefin/...
- tome 3y ago
  Yes, you're right, thank you!
naasking 3y ago
> I prefer the implicit version and disagree with the claim in the article that it will lead to dozens of arguments. What we normally do when we have dozens of things that belong together is that we package them all up into data structures/records/objects that group related functionality. This was the suggestion of "A Second Look at Overloading" [1], where they eliminate class declarations and simply declare which individual functions/operators are overloaded. [1] https://dl.acm.org/doi/10.1145/224164.224195 https://dl.acm.org/doi/10.1145/224164.224195

by tome 3y ago

lioeters 3y ago

> I prefer the implicit version From the context (hehe) I think you meant you prefer the explicit version? Personally I'd prefer to make things explicit, even if it's more verbose. > Bluefin is a Haskell effect system with a new style of API. > It is distinct from prior effect systems because effects are accessed explicitly through value-level handles which occur as arguments to effectful operations. https://github.com/tomjaguarpaw/bluefin/blob/master/bluefin/src/Bluefin.hs https://github.com/tomjaguarpaw/bluefin/blob/master/bluefin/...

tome 3y ago
Yes, you're right, thank you!

naasking 3y ago

> I prefer the implicit version and disagree with the claim in the article that it will lead to dozens of arguments. What we normally do when we have dozens of things that belong together is that we package them all up into data structures/records/objects that group related functionality. This was the suggestion of "A Second Look at Overloading" [1], where they eliminate class declarations and simply declare which individual functions/operators are overloaded. [1] https://dl.acm.org/doi/10.1145/224164.224195 https://dl.acm.org/doi/10.1145/224164.224195