What if the underlying overhyped and overapplied technology underlying both blockchains and AI, the original solution in search of a problem that gave rise mostly to expensive toys, unreliable devices, and epic startup crashes, was microprocessors
Tuples and curried functions are nice for toys, but they are industrial Haskell's worst enemy. If you're going to be able to jump into a big repo and understand stuff, you need to see record field names.
@chris__martin It's way too easy to fall into the trap of adding yet another positional parameter to a function, rather than taking the effort of refactoring to a record.
A library that has been greatly improved by the use of records is Servant. Trying to define a big REST API without NamedRoutes seems like a chore.
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.
@clementd I should try, but HasField uses functional dependencies and I don't know if they're enough to build the FieldType type family on top of them. IIRC, functional dependencies carry less type-level "evidence" than type families, or something like that?
@exa The label seems to be working at the term level, doesn't it? I was looking for something at the type level. A type-level "record dot accessor" if you will.
Also, "dani-servant-lucid2" has a public sublibrary with extra definitions, but it seems as if Hackage doesn't display info for public sublibraries yet.
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.
btw, why am I throwing a ServerError with HTTP code 200?
I think ServerError is somewhat misnamed: in reality, it can represent any type of response, not only errors.
It's a kind of escape hatch from the typing strictures of Servant: it lets you return any status code and respose body for a request, not just the ones specified in the type-level API.
"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."
