BNFC3: A compiler front-end generator.

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.

[maintain] [Publish]

The BNF Converter is a compiler construction tool generating a compiler front-end from a Labelled BNF grammar. It was originally written to generate Haskell code, but can also be used for generating Agda, C, C++, Java, Ocaml and XML code.

Given a Labelled BNF grammar the tool produces: an abstract syntax as a Haskell, Agda, C, C++, Ocaml module or Java directory, a case skeleton for the abstract syntax in the same language, an Alex, JLex, or Flex lexer generator file, a Happy, CUP, Bison, or Antlr parser generator file, a pretty-printer as a Haskell, Agda, C, C++, Java, or Ocaml module, an XML representation, a LaTeX file containing a readable specification of the language.


[Skip to Readme]

Properties

Versions 3.0
Change log CHANGELOG.md
Dependencies array (>=0.5 && <0.6), base (>=4.9 && <5), BNFC3, containers (>=0.6.0.1 && <0.7), deepseq (>=1.4.2.0 && <1.5), directory (>=1.3 && <1.4), extra (>=1.7.9 && <1.8), filepath (>=1.4 && <1.5), microlens (>=0.4.12 && <0.5), microlens-mtl (>=0.2.0.1 && <0.3), microlens-th (>=0.4.3.9 && <0.5), monad-control (>=1.0.2.3 && <1.1), mtl (>=2.2.2 && <2.3), optparse-applicative (>=0.16 && <0.17), pretty-show, prettyprinter (>=1.7.0 && <1.8), prettyprinter-ansi-terminal (>=1.1.2 && <1.2), split (>=0.2.3.4 && <0.3), string-qq (>=0.0.4 && <0.1), transformers (>=0.5.2) [details]
License BSD-3-Clause
Author Andreas Abel and Beatrice Vergani
Maintainer bnfc-dev@googlegroups.com
Category Parsing
Home page https://bnfc.digitalgrammars.com
Bug tracker https://github.com/BNFC/bnfc3/issues
Source repo head: git clone git://github.com/andreasabel/bnfc3.git
Uploaded by AndreasAbel at 2022-07-22T09:02:45Z

Modules

[Index] [Quick Jump]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Readme for BNFC3-3.0

[back to package description]

BNFC 3.0

A reimplementation of BNFC.

Goals of BNFC

BNFC is a wizard to generate parsers and printers in different programming languages (PL) from a readable grammar in Labelled Backus-Naur Form (LBNF). Its prime intended uses are those:

  1. In teaching, to speed up the generation of a compiler front-end so students can focus on the more interesting back-end.

    The multi-backend structure of BNFC is especially important for the use in teaching, since not all students use Haskell.

  2. In computer language prototyping, to quickly get basic infrastructure (parser, printer, AST).

  3. In more serious software projects, to get started on a parser which may later be hand-edited to implement more subtle language features.

A common benefit of BNFC to all users is that they do not need to master the ugly ad-hoc syntax of parser generators (I only say "yacc").

Goals derived from these use cases are:

  1. BNFC should be correct, i.e., have a specification and follow it. This is a common goal of much of PL-related software, I suppose.

  2. BNFC should be user/beginner-friendly.

    • BNFC should give comprehensible error messages with error location.
    • BNFC should alert users of common mistakes. Example: coercions applied to wrong range, or duplicating a parenthesis rule.
  3. BNFC should output pretty code that can serve as basis for hand-editing. Users do look at the generated code.

    • Well-chosen identifiers.
    • Tabular alignment where possible.
    • Comments pointing to the origin of generated code (from which grammar rule).
  4. BNFC should be robust.

    • Generated code should build in the overwhelming majority of cases. Clashes with language keywords and builtin identifiers should be avoided.

    • BNFC should evolve in a backwards-compatible way if reasonable.

Problems with BNFC Version 2

From the user perspective:

From the developer perspective:

  1. Hard to maintain.

    • Internal data structures do not express invariants.
    • Lots of cut-and-paste code.
    • Backends do not share common routines, each backend generates output from scratch.
    • Feature bloat (rules, define, layout, left-recursion introduction).
  2. Hard to extend.

    • Each backend has to reinvent the wheel, since common API for backends is missing.
    • Feature bloat: obscure features like define and layout make backends harder to implement.

Goals of reimplemenation

  1. Improve maintainability of BNFC

    • better internal data structures that express invariants
    • common API for backends
    • well-structured testsuite that can be run in reasonable time and on CI servers
  2. Improve robustness and UX of BNFC

    • thorough "type" checking of the LBNF with good error message.
  3. Improve output of BNFC

    • e.g. use readable, common names for symbols in the parser (e.g. LPAREN for "(")
    • e.g. use pretty-printing library for Haskell printer