If you are looking for real-world code for an effect system, not just a PDF paper, you should probably look at the eff library: https://github.com/hasura/eff
The acknowledgement section on that GitHub README mentions this paper.
The acknowledgement section on that GitHub README mentions this paper.
`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 """
* 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]
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.htmlThe 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