[Haskell-cafe] Correct parsers for bounded integral values

[Olaf Klinke]

> Both approaches
> require one comparison per digit read (the number-counting approach
> needs to count the digits and test whether the limit of this counter
> has been reached, the “modulo” approach needs to check whether `lim`
> has been reached).  And both approaches need to accumulate the digits
> read so far (digit-counting collects the digits and converts them to
> a
> value just before reading the final digit, “modulo” accumulates the
> final value on the go).

Some, but not all, parser combinator libraries have a user-defined
state component. Since the parser updates its internal state anyways,
the overhead might be smaller than anticipated. 
If the parser is not a monad transformer, a workaround is to newtype
the region containing a number literal, so that the parser state can
accomodate the extra accumulator.

https://hackage.haskell.org/package/parsec-3.1.18.0/docs/Text-Parsec.html#t:ParsecT
https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-Internal-Types.html#t:State
https://hackage.haskell.org/package/megaparsec-9.7.0/docs/Text-Megaparsec-State.html#t:State

> I don't know where to start, `base` just always
> happened to be there already.  I.e., could someone please help me to
> get a simple setup (my usual modus operandi is the shell, cabal, and
> an editor) where the base library is accessible for modification and
> testing?

base is just a package like others. You can download a copy from
hackage, unpack and build it with your build tool of choice, can't you?
(Never thried that myself, though.) 

If parsing speed is a concern: For those parsers that build on a parser
type class (megaparsec or the parser-combinators package) one can
implement a simple parser that has less book-keeping overhead and embed
it into fancier parsers, calling the proper parser on the input only in
case something goes wrong. 

https://hackage.haskell.org/package/faster-megaparsec

Olaf