In Servant, the ServerError type has an Exception instance https://hackage.haskell.org/package/servant-server-0.20/docs/Servant-Server.html#t:ServerError
You might speculate that when throwing a ServerError using liftIO . throwIO in a Handler, the ServerError is automatically caught and served as a response, but it ain't so: it's treated as just another exception, and the response code is 500.
"A relative reference that begins with a single slash character is termed an absolute-path reference. A relative reference that does not begin with a slash character is termed a relative-path reference."
You might say "Well, that's not a problem, just make those intermediate components that don't care about the connection polymorphic over MonadUnliftIO! Later, when composing the application, they will be injected a repository that does know about the ReaderT and the connection. Problem solved."
That's true, but what if I wanted those intermediate components to be as dumb as possible? Just plain records of functions in IO, no monad transformers, and no polymorphism over the monad, either?
As an alternative to ReaderT and/or polymorphism over the effect monad, I could try to implement some form of "thread-local" storage. 🤔 Some kind of map indexed by ThreadId which would be injected only into those components (like the repository) that require the request-scoped info.
Entries would be allocated / deallocated in the "hoistServer" callback, much like with the ReaderT solution.
Intermediate components could use IO for effects and remain blissfully innocent of the shenanigans.
The problem of course is that this solution would be less type-safe. If the repository expects an entry for the current ThreadId to exist in the map, and we forgot to set it earlier in the "hoistServer" callback, that would be a runtime error.
In-depth exegesis of the meaning of single letters in my #Git aliases. I'm being so productive you wouldn't believe. Productivity is off the charts right now.
Relatedly, it would be a nice feature for Haddock if the instances local to a module could be sorted and grouped for the purposes of documentation and telling a story.
Like "These are the instances for tuples of various sizes" or "this is the base case and these are some instances that recurse".
"registry"-like approaches do seem to make it easier to reuse previously assembled application contexts because the wiring is done through a dictionary-like data structure. You can easily overwrite any key with a different implementation, or with a mock.
I vaguely feel that the AGI singularity cult comes from a mode of thinking that's implicitly aligned with Catholic Neo-Platonism. Like, if everything in the universe is either sentient or it isn't and there's no grey area between then you end up in an absolutist position on abortion. So every AI is either AGI or it isn't, and every AGI is God-like.
It's kind of the exact opposite of your basic starting point of queer theory, that binaries don't exist in nature.
