tomjaguarpaw / bluefin

Bluefin

Bluefin is an effect system for Haskell which allows you, through value-level handles, to freely mix a variety of effects including

• Bluefin.EarlyReturn, for early return
• Bluefin.Exception, for exceptions
• Bluefin.IO, for I/O
• Bluefin.State, for mutable state
• Bluefin.Stream, for streams

Introduction

For an introduction to Bluefin, see the docs in the Bluefin module.

Examples

There is an bluefin-examples package which you can see in this repository at bluefin-examples/src/Bluefin/Examples.

Acknowledgements

Tom Ellis would like to thank many individuals for their work related to effect systems. Without the work of these individuals, Bluefin would not exist.

• Oleg Kiselyov, particularly for his work on effects and delimited continuations

• Michael Snoyman, particularly for his work on conduit and the ReaderT IO pattern

• Gabriella Gonzalez, particularly for her work on pipes

• Alexis King, particularly for her work on effect systems and delimited continuations

• David Feuer, particularly for his observation about handlers and rank-2 types

• Andrzej Rybczak for his work on effectful

• Francois Pottier for "Wandering through linear types, capabilities, and regions"

• Jasper van de Jeugt, particularly for promoting the handle pattern

• Michael Thompson, for his work on streaming

• Ningning Xie and Daan Leijen, for their work on Koka

• Andrej Bauer and Matija Pretnar, for their work on Eff

bluefin's Issues

Difference to effectful

Hey there!

I am really intrigued by bluefin, it looks very cool. I am however a bit confused but the design and was hoping to for some clarifying discussion.

The handler as function arguments pattern is indeed very expressive and simple. However it immediately triggers a: So many function parameters, maybe this would be easier with a Reader? Which kinda defeats the purpose. I have a few questions about that:

• passing handles around as values feels runtime heavy, can that be a performance problem?
• Since the handlers should be known at compile time could we make the the handler parameters type level arguments? e.g. with visible forall in 9.10?
• once we have that, can't we try to infer the type arguments by making them implicit? Worst case that doesn't help because GHC can never infer the type, but maybe it can?
• Once we are there, isn't that quite similar to effectful? But bluefin seems to be more potent in the kind of effects which can be implemented. Is that really because of the termlevel handlers or is there something else at play?

Thank you for indulging me.

Use concrete/abstract or static/dynamic terminology consistently

We should choose whether we distinguish between the types of user-defined effects using "concrete/abstract" or "static/dynamic" terminology. I prefer the former but existing effect systems seem to use the word "dynamic" so maybe we should use the latter. In any case, we shouldn't mix the terminologies!

Use "capability" rather than "handler"

Until now I've been talking about "handlers" but it seems there is some precedent for calling them "capabilities", for example Martin Odersky's Keynote at ICFP '24. Perhaps we should switch.

Is something like a natural transformation from one effect to another possible?

I really like the lightweight approach bluefin takes, and that it distinguishes from other libraries - from my, a pure user, perspective, the value level brings some benefits, like implicit tagging or simpler/more sensible compiler warnings.

However since the effects are more directly interpreted, I wonder if it is possible to write natural transformations or interceptors in an easy way - I believe that with dynamic effects some kind of proxying might be possible - but what about the transformation? Is it possible to transform the effect without running it?

Btw - as a stackage curator - I like to do some advertising - since you already have some libs on stackage, would you mind adding bluefin also?

Thanks for sharing your ideas and the code to the community 🥇

Why two packages instead of a public sub-library?

I can't see a good reason not to have bluefin-internal as just a public sub-library of bluefin, unless it's actually advantageous to be able to mix-and-match versions. Which seems unlikely since AFAICT bluefin just re-exports bluefin-internal.

What's the benefit of "higher-order effects", e.g. local

Following up from re-xyr/cleff#31 (comment) and #14 (comment), I don't understand why "higher-order effects" are useful, as opposed to just writing handlers. @re-xyr clarifies that

The difference between a higher-order operation and a handler is that the former is an abstraction of the latter, just like how a (first-order) effect operation is an abstraction of a monadic action.

but I still can't think of an example of a higher-order effect that couldn't be implemented just as well as a handler. For example, MonadReader has

local :: (r -> r) -> m a -> m a

but why is local f m that better than (in Bluefin terms)

\reader -> do
    r <- ask reader
    runReader (f r) m

MTL interop

Looks like you can't do seamless (i.e. without newtypes) MTL style effects interop, as already evidenced by how Eff can't have a MonadIO instance?

Links broken in haddocks

bluefin/bluefin/src/Bluefin.hs

Lines 127 to 128 in d88d7df

	-- in terms of effectful: 'Bluefin.Bluefin.Coroutine's and
	-- 'Bluefin.Bluefin.Compound' effects.

Links to Coroutine and Compound are broken on hackage and your site — I haven't checked the rest.

Can a complete example akin to a "Getting started" be added?

Maybe I just didn't know where to look but there seems to be no complete, self contained example, such as a Main.hs file showing necessary LANGUAGE pragmas and where to get typical imports from. It's great that the documentation has examples, and I think this project would be even more approachable if it had one blob of code you can just copy into your editor and modify it.

Add this explanation of why we need IncoherentInstances to the Haddock

https://discourse.haskell.org/t/bluefin-a-new-effect-system/9395/9?u=tomjaguarpaw

Explain why bracket is "pure"

Summarize this discussion: https://twitter.com/tomjaguarpaw/status/1785604044473487548

How to have dynamic effects that take handles as arguments

As an example, suppose that we have a file system effect. We might want to be able to handle errors in the readFile function, but still have it be dynamically interpreted while using some other unknown effects. What we want is something similar to the incorrect code below.

data Filesystem e = Filesystem {
   readFile :: Exception FileSystemError e -> FilePath -> Eff e String,
   ...
}