Skip to content

Switch to more modern parsing/pretty-printing libraries #27

Open

Description

@taktoa

You guys currently depend on parsec and pretty for parsing and pretty-printing respectively. Assuming that you are not doing this purely as a way of minimizing your dependency footprint (since pretty at least is a boot package that ships with GHC), I would recommend that you migrate to more modern parsing/pretty-printing libraries. These can improve parsing speed, parser error message readability, and code reusability.

For parsers, there are two main options, depending on what matters to you:

  • If speed is important, then you should use the parsers library to write a typeclass-generic parser, which can then be instantiated with a concrete parser type from trifecta when debugging (trifecta is slow but has good error messages) or with a parser type from attoparsec in production (attoparsec is fast but has bad error messages).
  • If nice error messages are important and you want to migrate from your parsec parser easily, but speed is not particularly important, megaparsec is a good option. In the version 6 and above of megaparsec, primitives are provided that make it as fast as attoparsec.

For pretty-printers, my main recommendation is prettyprinter, which is a pretty comprehensive replacement for all the pre-existing pretty-printing libraries in Haskell. It supports terminal output with ANSI colors, HTML output, it doesn't have name clashes with common operators, and it uses Text for performance.

Activity

  1. dlthomas commented on Mar 9, 2018

    @dlthomas
    Contributor

    So far as I'm aware, parsing speed hasn't been an issue. Moving to megaparsec might be good, but should be weighed against "if it ain't broke" (it was fairly new when the project started, and there hasn't been enough of an impetus to switch).

    As to pretty printing, that's presently mostly unimplemented; I don't expect there would be any objection to switching away from pretty if it came with a diff that did more.

  2. dlthomas commented on Mar 9, 2018

    @dlthomas
    Contributor

    Two other notes:

    1. Choice of parsing library could be per-dialect with minimal drawbacks, so migration could be gradual or limited to new packages (or not - just worth noting we have the flexibility)
    2. A much more interesting change to parsing would be something that could handle incomplete statements, but that's also a much bigger change generally.
  3. Fuuzetsu commented on Mar 14, 2018

    @Fuuzetsu

    uu-parsinglib has error-correcting facilities, depending on what kind of incomplete statements you're after, this might be something to consider

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions