flatparse 0.5.4.0 → 0.5.4.1

raw patch · 2 files changed

+6/−3 lines, 2 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

• README.md +5/−2
• flatparse.cabal +1/−1

@@ -17,7 +17,7 @@  ## Features and non-features -* __Excellent performance__. On microbenchmarks, `flatparse` is 2-10 times faster than `attoparsec` or `megaparsec`. On larger examples with heavier use of source positions and spans and/or indentation parsing, the performance difference may be greater, because `flatparse`-s handling of source positions is heavily optimized. Compile times and executable sizes are also significantly better with `flatparse` than with `megaparsec` or `attoparsec`. `flatparse` internals make liberal use of unboxed tuples and GHC primops. As a result, pure validators (parsers returning `()`) in `flatparse` are not difficult to implement with zero heap allocation.+* __Excellent performance__. On microbenchmarks, `flatparse` is 2-10 times faster than `attoparsec` or `megaparsec`. On examples with heavier use of source positions and spans and/or indentation parsing, you can expect a bigger gap between `megaparsec` and `flatparse`. Compile times and executable sizes are also significantly better with `flatparse` than with `megaparsec` or `attoparsec`. `flatparse` internals make liberal use of unboxed tuples and GHC primops. As a result, pure validators (parsers returning `()`) in `flatparse` are not difficult to implement with zero heap allocation. * __No incremental parsing__, and __only strict `ByteString`__ is supported as input. However, it can be still useful to convert from `Text`, `String` or other types to `ByteString`, and then use `flatparse` for parsing, since `flatparse` performance usually more than makes up for the conversion costs. * __Only little-endian systems are currently supported as the host machine__. This may change in the future. However, `flatparse` does include primitive integer parsers with specific endianness. * __Support for fast source location handling, indentation parsing and informative error messages__. `flatparse` provides a low-level interface to these. Batteries are _not included_, but it should be possible for users to build custom solutions, which are more sophisticated, but still as fast as possible. In my experience, the included batteries in other libraries often come with major unavoidable overheads, and often we still have to extend existing machinery in order to scale to production features.@@ -33,6 +33,9 @@   overhead in performance and code size compared to `Basic`. In microbenchmarks   and small parsers, the performance difference between `Basic` and `Stateful`   is more up to the whims of GHC and LLVM, and is a bit more "random".+* [`FlatParse.Minimal`][minimal] is a stripped-down version that has no error reporting features and+  no support for efficient backtracking. It is intended for deserialization workloads. Currently the+  API is also rather small. More functions might be added in the future.  ## Tutorial @@ -72,7 +75,7 @@ |lambda term/megaparsec | 5.35 ms| |lambda term/parsec | 17.7 ms| -Object file sizes for each module containing the `s-exp`, `long keyword` and `numeral csv` benchmarks.+Object file sizes for each module containing the `s-exp`, `long keyword`, `numeral csv` and `lambda term` benchmarks.  | library    | object file size (bytes) | | -------    | ------------------------ |

@@ -5,7 +5,7 @@ -- see: https://github.com/sol/hpack  name:           flatparse-version:        0.5.4.0+version:        0.5.4.1 synopsis:       High-performance parsing from strict bytestrings description:    @Flatparse@ is a high-performance parsing library for strict bytestring input. See the README for more information:                 <https://github.com/AndrasKovacs/flatparse>.