"A strict binding (with a top level !) should not be thought of as a regular pattern binding that happens to have a bang pattern [...] on the LHS. Rather, the top level ! should be considered part of the let-binding, rather than part of the pattern."
I didn't know about this distinction! Found out about it when fiddling with linear let-bindings in GHC 9.10.1.
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.