Abstract

Parser combinators are a middle ground between the fine control of hand-rolled parsers and the high-level almost grammar-like appearance of parsers created via parser generators. They also promote a cleaner, compositional design for parsers. Historically, however, they cannot match the performance of their counterparts. This paper describes how to compile parser combinators into parsers of hand-written quality. This is done by leveraging the static information present in the grammar by representing it as a tree. However, in order to exploit this information, it will be necessary to drop support for monadic computation since this generates dynamic structure. Selective functors can help recover lost functionality in the absence of monads, and the parser tree can be partially evaluated with staging. This is implemented in a library called Parsley.

Highlights

  • For functional programmers, parser combinators provide a clean and flexible approach to constructing parsers

  • These constructors mirror the structure of the parser combinators themselves: the operations that the user interacts with are all functions that serve as wrappers around the combinator tree constructors

  • This reflects the advantage of our library that no specialist knowledge of the combinators is needed to write parsers: this seems favourable to the user, at least

Read more

Summary

INTRODUCTION

Parser combinators provide a clean and flexible approach to constructing parsers. This is the main disadvantage of parser combinators: the job of writing the parser is straightforward but results in a lot of extra interpretive overhead. The result of pfilteredByf is the value x parsed by p if f x holds true and failure otherwise This has a static structure: the analyser will know that filteredBy either returns some value, or fails, but not which branch is executed. As we will see moving forward, the secret to implementing the filter combinator and other static behaviours with dynamic choices is to restrict our power to selective functors [Mokhov et al 2019] This will give us access to some control-flow constructs, but still permit the static analysis needed to compile away all of the abstraction and overhead

Section 4.1
BACKGROUND
THE COMBINATOR TREE
Combinator Tree Optimisation
Recursion and Let-bindings
Analysis
COMPILATION TO ABSTRACT MACHINE
The Machine
Machine Optimisation
Consumption Analysis Revisited
STAGED INTERPRETATION
Interpreting a Machine
Background
Staging the Interpreter
BENCHMARKS
Branflakes
JavaScript
Nandlang
RELATED AND FUTURE WORK
Future Work
CONCLUSION
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.