The acknowledgement section on that GitHub README mentions this paper.
The ecosystem is massive.
Cons: TypeScript is a great type system but requires some investment to get the best out of it, it's also very verbose.
Pros: you have access to the entirety of the TypeScript ecosystem.
Crazy claim to make without providing any evidence
* Polysemy: https://hackage.haskell.org/package/polysemy
* effectful: https://hackage.haskell.org/package/effectful
* Bluefin: https://hackage-content.haskell.org/package/bluefin/docs/Blu...
[Disclosure: Bluefin in my effect system]
`eff` is based on delimited continuations (which Alexis had to build into GHC), it is not using `Freer`. If you want to look at an effect system in Haskell that actually has been used in production AND is based on this paper then look at `freer-simple`: https://hackage.haskell.org/package/freer-simple
No it is not high performance, but neither are any other Haskell effect systems and performance is relative to your problem domain. It also has the benefit of being implemented very similarly to Oleg's paper making it a lot easier to learn from then most other options.
This is not true. IO-wrapper effect systems (in practice, effectful or Bluefin) have as good performance as Haskell's IO monad, that is to say as good as you can get in Haskell.
that said, your library is really cool. : )
You can look at my table of "A Comparison of Effect Systems at a Glance" to see all the tradeoffs:
https://hackage-content.haskell.org/package/bluefin-0.2.0.0/...
And thanks! Glad you like it. Feel free to reach out to me at any time if you'd like any help with it or have any questions or comments.
This is second hand information and may apply more so to effectful then bluefin. I have just done some pretty minimal test projects with bluefin and effectful but I was told:
""" It's not too hard to make segfault if you organize your higher order effects just right.
It's been a while but i think you just return a continuation with the effect you just handled, and then all of a sudden it's not in scope and yet you need to still handle it.
And the tricks they use to make things go fast don't work in this case and things go boom """
https://koka-lang.github.io/ https://effekt-lang.org/
Frank is pretty old now but perhaps a simpler implementation: https://github.com/frank-lang/frank
But the things these languages are experimenting with are low-level implementation details that wouldn't be amenable to embedding. There's no escaping the Haskell GC.
[1] https://hackage.haskell.org/package/atom
These languages you mentioned repeat Rust's mistake.
Rust's type system includes rules that remove definitions from the scope/environment. This is inherent and obligatory for uniqueness/linear types type systems.
At the time Rust was conceived, Haskell had HList library [2] and Beyond Monads [3] extended state monad. Combining both would embed into Haskell most, if not all, Rust at the time, allowing to pursue research of how to combine borrow logic with algebraic effects. But Rust's developers preferred to go OCaml implementation (syntax first) way and not to pursue complexity issues of semantics.
[2] https://hackage.haskell.org/package/HList
[3] http://blog.sigfpe.com/2009/02/beyond-monads.htmlAs a user, I think effect libraries in Haskell trade off between five main constraints:
* Typelevel wizardry
* Boilerplate
* Performance
* Ability to handle "higher-order" effects (e.g., `bracket`)
* Safety (e.g., not accidentally leaking effects beyond their scope)
The most compelling libraries I've seen from the industrial perspective are the "IO-wrapper" libraries like `cleff`, `effectful`, and `bluefin`. These libraries tend to give good performance, can handle higher-order effects, but trade off a little safety to get the typelevel stuff down a bit. Of these, I currently favour `effectful` but am keeping an eye on `bluefin` (which is very close to `effectful` but with explicit handle-passing). The explicit handle-passing in `bluefin` seems to get the typelevel down a bit more in exchange for asking the user to write a little more boilerplate to explicitly pass handles around.
I'm willing to bet the contrary: that IO-wrapper effect systems are the future of Haskell (particularly Bluefin, but then that's my library, so I would say that).
> You can't statically guarantee that only, for example, the DB has side effects in a function
Yes, you absolutely can.
But you can also stratify in the other direction. ‘Pure’ functions aren't real outside of mathematics: every function can have side effects like allocating memory, possibly not terminating, internal (‘benevolent’) mutation, et cetera. When we talk about ‘pure’ functions we usually mean that they have only a particular set of effects that the language designer considered ‘safe enough’, where ‘enough’ is usually defined with reference to the ergonomic impact of making that effect explicit. Algebraic effects make effects (and importantly effect composition — we got here in the first place because we were fed up of monad transformers) more ergonomic to use, which means you can make more effects explicit without annoying your users.
sctb•2mo ago