Maybe it was already asked before but what are benefits of Bluefin compared to using plain IO functions? Why should I use foo :: (e1 :> es, e2 :> es) => Handle1 e1 -> Handle2 e2 -> Eff es Foo instead of a plain foo :: Handle1 -> Handle2 -> IO Foo

Why don’t you all go and build something with an effect system, and come back with actual production insights? I think I’ve heard this before…yes, that’s what it was: …can we just wait until the GHC developers choose one, so it can be deemed as recommended workable?

The second one is tightly coupled to the effect system. It’s impossible to convert to a pure IO action and pass to a non-Eff subsystem … It’s only reusable within Eff framework and unusable outside. Doesn’t look too modular. This is not true. There is no coupling to the effect system (assuming we…

[image] vshabanov: Agreed. The more pure code and the less IO the better. If one wants better control, it should be a discreet decision, not a jump on a bandwagon. That’s good news for effectful and Bluefin then, because you can use them in internal components without effecting external APIs…

[image] vshabanov: It’s only reusable within Eff framework and unusable outside. I agree, but not everything has to be reusable outside the context it is important in. I mentioned codebase, but that is not good enough. I’d draw a distinction between application/library code. Then I’d agree th…

Because I also can’t remember everything: [image] The issues with effect systems Learn Hello, I’ve been rather interested in effect systems for months at this point and I’ve been researching their benefits and issues. I do know that their benefits include: Potentially b…

As someone who doesn’t have a strong opinion on this topic I’d say ultimately it depends on the kind of applications that you write and on personal preference. However I’d like to point out another aspect, that I don’t see mentioned in this discussion, namely that Haskell is not a “batteries-includ…

[image] BurningWitness: In my view the only true benefit to effect systems is that it’s the only sane way of getting … a mirror test system that behaves exactly the same, but calls test versions of all real-world things it links to. There are many ways to achieve mocking without effect system…

[image] vshabanov: There are many ways to achieve mocking without effect systems Production services with test data is QA territory; Built-in mocking means your declarations and implementations for both the production and the test versions have to live in the same module, whereas they mo…

[image] atravers: Then here’s the challenge for you and everyone else who thinks IO a is now bunglesome and needs diluting: type IO a = Eff All a …use your preferred system of effects to provide a Haskell declaration for All . I think I finally understood this concern. Effect systems (those…

[image] jeukshi: [The effect systems mentioned in this topic] are about built-in/custom effects and restricting functions to specific effects. Unfortunately effects aren’t always so easily restricted: Why does this matter? [image] jeukshi: […] those libraries provide an easy way to mak…

Haskell Community

Why use an effect system?

Learn

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled