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:... https://hackage.haskell.org/package/attoparsec-0.14.4/docs/Data-Attoparsec-I... https://hackage.haskell.org/package/megaparsec-9.7.0/docs/Text-Megaparsec-St...
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