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?
So, if I'm getting this right, parsing failures that consume input are treated differently from parsing failures that don't consume input, and only the latter interact in the expected way with combinators like "many" and "optional"?
Ok, the heart of the matter is the Alternative instance on which the "many" and "optional" combinators depend.
As the docs say, "empty is a parser that fails without consuming input". So a parser that fails while consuming input can't be equated to "empty". I guess the moral of the story is that one should almost always use "try" with Alternative-y combinators.
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.
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.