That’s a really well-written blog post! I feel this is an important program design topic, and one which the PureScript language punts to user-land without any advisement. I’m happy to see it discussed here!
I saw Matt Parsons updated an older blog post of his on this topic. I found it a bit hard to understand his current thinking, so if anyone wants to digest it and write it as a blog post, I would read it! I think he landed at “capability-sets as records are a good idea, and having them be implicit parameters to functions using type classes is a good idea.”, so correct me if that’s wrong.
At the very least I succeeded in being brief, which was a goal. I’m worried that it’ll appeal only to people who already know about this, but I decided to not try to talk down to the reader too much.
It’s becoming clear to me from engaging more in the Twitter community that there’s a lot of despair going around regarding this very topic and since you can hit both languages for free in one go I decided to also write it with PureScript in mind.
As a point in the design space, I think this transfers beautifully into one of the most common patterns of ReaderT env m a as long as one is willing to say “Yes, we can use mutable variables of different kinds (TVar, MVar, IORef, etc.) and limit their exposure via ad-hoc constraints”. The real value here is being able to be 100% precise in signalling what you’re doing, not in never using mutable state or side-effects, etc.
That’s potentially a follow-up post (and could’ve been covered in this one had I not wanted to keep it brief) but I’ve yet to be able to package it up as neatly as this one.
I sort of get it, which I think means I don’t really get it. If anyone has a neat example that concretely shows exactly what we’re solving and why I’d also be really grateful. ReaderT + constraints on state variables + effect functions seems a very low bar to limbo under and I’m not sure I even get the value proposition.