AFAIK, there's not an easy way in Haskell to inspect at the type level what type a field has in a record.
What I mean is that that there doesn't seem to be a type family like
type FieldType :: Type -> Symbol -> Type
that we could invoke in ghci like
:kind! FieldType Person "age"
Why would I want this? For libraries like servant and rel8 that use parameterized records where the types of the fields vary heavily with the type parameter.
If your branch has a good number of commits since it diverged from main, rebasing can sometimes seem like a Sisyphean task. Because each commit is applied independently, you often end up resolving merge conflicts again and again in the same places, conflicts that a merge would make you resolve together in one go.
To avoid that, I sometimes squash together all the commits in my branch before rebasing on top of main. But then of course I lose the structure of the separate commits.
@nshephard Actually, I've found some links that talk about rerere helping even for single rebases (?) so maybe I'm wrong. But I'm still unsure about why it would work 🤔
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?
I know that Megaparsec doesn't backtrack automatically and that you have to use "try" for that, but this behavior of "many" was unexpected. Why oh why doesn't it parse the final space? https://stackoverflow.com/a/78355045/1364288
Maybe I didn't read the documentation thoroughly, but I don't think it's actually spelled out in the Haddocks?
@DiazCarrete
+1 for the other suggestion here: do not eat space before the lexemes (as beginner tutorials tend to show) -- always eat it after the lexemes (and only after the lexemes!), and do it reliably. Hard-learned lesson.
@DiazCarrete IIRC, we don't "try" by default because it can cause excessive backtracking, and having that even be a possibility holds references to things, increasing memory usage, and decreasing performance.
So, yeah, anytime you want to "noncommittally consume", you have to use try explicitly.
@DiazCarrete That's what I do, yes. newtype Semantic2 = MkSemantic2 { unSemantic2 :: Semantic1 }
Though sometimes I do something different, like newtype Subset = AssertSubset { asSuperset :: Superset } for things where the rep. sharing is more practical, even if the syntax isn't actually the same, like Email/Text or PhoneNumber/Int64 since construction will generally be through something like isEmail :: Text -> Either ParseFailure Email or inputPhone :: Natural -> Maybe PhoneNumber
@DiazCarrete with type classes in Haskell my personal ideology is to avoid them unless you're very sure that they are really a good model of your domain and they have specific laws. But indeed, many classes and instances - in base even - don't satisfy that.
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.
@DiazCarrete That being said, when working with servant in Haskell, I ended up putting the public API types in a separate cabal package, that was depended upon by both the server implementation and the clients. This made a lot of things considerably simpler
"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.
@DiazCarrete That slide seems to misrepresent effect systems. It is easy to replace just runInputConst:
runAllEffects (runInputDifferently program)
The runInputDifferently effect handles the Input Config effect and it leaves an unused Input Config in the list of effects. So the runInputConst config handler in runAllEffects will not be used.
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".