Early adopter feedback

[tomjaguarpaw]

I am seeking feedback from early users of Bluefin, for example

• descriptions of uses cases that work well, and ones that don't
• any particular rough edges or inconveniences experienced with the library
• any useful patterns you have discovered
• anything else at all you want to share

cc @maralorn @jeukshi @cideM @oberblastmeister @raehik

These are the public projects using Bluefin that I am aware of. They might serve as a useful basis for discussion.

• https://github.com/jeukshi/kosem
• https://github.com/jeukshi/bluefin-log-base
• https://github.com/raehik/streampatch

[tomjaguarpaw]

If you've used Bluefin, please share your thoughts here!

[maralorn]

Okay, let me share a few thoughts. Note that I don’t have very much experience with other effect systems (besides transformers, maybe) so I am not saying that the problems I encountered are particularly bad in bluefin, it’s just observations I had and they might not be actionable.

• I ported https://reflex-frp.org which uses mtl to a bluefin effect in https://code.maralorn.de/maralorn/config/src/branch/main/packages/kass/lib/Bluefin (however I discontinued the project in which I used it, so this experiment is currently unused.)
• I thought working with bluefin was really pleasant to work with. The handle approach gives it a conceptual clarity which limits mental overhead.
• I think my biggest pain point was dealing with the typelevel tags. They work, but I frequently ran into situations where I had to do typelevel proofs which the compiler couldn’t infer. I partially had to resort to writing some lemmas of which I was surprised to not find in bluefin. I am curious whether we should upstream them and make that collection of helpers more complete. Without experience in mathematics and theorem provers I don’t think I could have done that. And I still had to resort to unsafe at a few places. I suspect this is partially because I was designing a library, not just consuming it, and wrapping a rather intricate one instead of just implementing a new effect based on an existing one, but the complexity of this makes me shy away from recommending bluefin as a bread-and-butter solution for every use case right now. I think partially ghc is to blame here, but I would love for the tagging stuff to be less clunkly.
• As I said before I had to resort to quite a bit of unsafe wrapping/unwrapping of IO which simply means that I don’t feel super confident about the library I wrote. (Although I haven’t encountered any bugs at runtime.) This made me secretly fear that every Haskell application is a huge stack of unsafe code glued together by a thin veneer of pretend types. 😆
• One problem that we discussed elsewhere and which is a tough one is the use case of a handler which lets the user pass arbitrary effects to a child action but filters out some effect. I am not sure that there can even be a good solution for that but it’s a problem I encountered.
• Thinkg I haven’t dabbled with until now: I am currently missing a bit of guidance on parallelism and I am curious about the performance of the streaming utilities. I have made good experiences using streamly before which judging by API surface is a beast in comparison to bluefin.

[tomjaguarpaw]

Sadly I did that half a year ago so I am having cache misses

Ah OK, will I at least find all the things you talk about in https://code.maralorn.de/maralorn/config/src/branch/main/packages/kass/ if I go digging?

I need to run my eff stack inside the monadtransformer stack

Hmm, that sounds in general a bad thing to do, and I'm not surprised you got stuck there. Bluefin effects always ought to be "handled last", that is, it's OK to do runEff $ yieldToList $ \y -> Transformers.evalStateT $ ... something with get/put/yield y but not the other way round. In some cases you might even get it to work (it would be a bit like MonadBase/MonadLift) but I wouldn't recommend it.

When I simply couldn’t get it to work I owned that I have to do the unsafe stuff, which led to a simpler, but icky, implementation.

If you, or anyone, ever get into the situation where you think "I can't see how to do this with safe Bluefin combinators so I'll just do it with these internal hacks" then I consider than a critical Bluefin bug. Please report it as soon as possible by opening a new issue on the Bluefin issue tracker for immediate resolution.

[maralorn]

Ah OK, will I at least find all the things you talk about in https://code.maralorn.de/maralorn/config/src/branch/main/packages/kass/ if I go digging?

Yes.

Yeah, the "bad thing" I did was mainly caused by the fact, that reflex-frp has really elaborate and complicated transformer handlers which I didn’t want to understand and reimplement. That’s why I searched for a solution where I could repurpose the handlers to implement a bluefin handler. It’s most likely quite inefficient but it works and the bluefin API is relatively pleasant in the end. The different effects all boil down to reader or state in the end so it was possible.

If you, or anyone, ever get into the situation where you think "I can't see how to do this with safe Bluefin combinators so I'll just do it with these internal hacks" then I consider than a critical Bluefin bug. Please report it as soon as possible by opening a new issue on the Bluefin issue tracker for immediate resolution.

Fair, thank you. I should have done that. At that point I was very much doubting whether it was possible to pull of this translation at all, so I was very much in the anything goes mindset.

[tomjaguarpaw]

OK, I have removed all the uses of internal things (except converting between Eff and IO). You can have a look at the commit history here: https://github.com/tomjaguarpaw/maralorn-config/commits/tidy-bluefin/. Each of the commits explains how to apply the standard Bluefin way in each circumstance. All of the circumstances are bread-and-butter standard Bluefin except the last one inWidget, which is very mysterious to me!

(I didn't address converting between Eff and IO since I assumed it's something to do with interfacing with deeply-baked parts of Reflex which it's unlikely to be possible to improve without me having to learn a lot of Reflex.)

Having seen this, @maralorn, do you have any advice for how I can make it easier for Bluefin users to stay on the beaten track, rather than diverging into writing their own "proofs"? I'm very impressed you managed to succeed at that, actually. There are a couple of things that make me think your experience might not generalize to the average Bluefin user: firstly, Reflex looks like a complex beast to interface with (this is probably the most complex use of Bluefin to date), and secondly, your theorem proving experience might have made you more willing to dive in and try to write "proofs" whereas a user without that experience might stop and think "how should I change my code so it works with standard combinators". But nonetheless, I would welcome your advice for how I could have documented Bluefin, or designed the API, so that you wouldn't have got stuck in this way.

[maralorn]

Oh, well. Thank you for indulging my code. I think part of the problem was that I was a very early adopter, so several of the solutions you list or at least the more elaborate documentation were not available at the time of writing (at least not in this form). And some of the guidelines you are recommending I couldn’t find in the code.

• e.g. I remember specifically looking for whether every effect should implement handle, but the docs say only "can".
• Also I already suspected that I was using the wrong associativity, but the other way felt more logical to me, although I don’t remember why and the docs didn’t tell me. I think that is a foot gun which could be warned more eagerly in the docs. (Admitedly probably only a foot gun for more adventurous people who develop opinions about type level argument order and think they can get away with it.)

Lastly let me say that I didn’t get stuck, from my point of view. I succeeded in implementing the effect I wanted and the usage of the resulting library felt really pretty and I enjoyed it. So this wasn’t frustrating. Effectively you have pretty much rewritten most of the docs and API for implementing own effects by now, so I suggest we let this rest and the next time I encounter problems I will be in touch.

[tomjaguarpaw]

Ah, fair enough, and thanks for sharing it! It's great for me to see how people use Bluefin in practice and I'm really happy to hear you enjoyed it.

[maralorn]

By the way, just doing a refactoring on an mtl code base. I think seeing which parts of a do block actually use an available effect is amazing. bluefin has that and I miss it.

[tomjaguarpaw]

Ah cool, thanks for sharing, I appreciate it!