DOCSLIB.ORG

Ometa: an Object-Oriented Language for Pattern Matching

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ometa: an Object-Oriented Language for Pattern Matching OMeta: an Object-Oriented Language for Pattern Matching Alessandro, Warth, Ian Piumarta VPRI Technical Report TR-2007-003 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 OMeta: an Object-Oriented Language for Pattern Matching ∗ Alessandro Warth Ian Piumarta Computer Science Department Viewpoints Research Institute University of California, Los Angeles [email protected] and Viewpoints Research Institute [email protected] Abstract against a grammar—which itself is a collection of produc- This paper introduces OMeta, a new object-oriented lan- tions, or patterns—to produce parse trees. Several other guage for pattern matching. OMeta is based on a variant of tasks, such as constant folding and (na¨ıve) code generation, Parsing Expression Grammars (PEGs) [5]—a recognition- can be implemented by pattern matching on parse trees. based foundation for describing syntax—which we have Despite the fact that these are all instances of the same extended to handle arbitrary kinds of data. We show that problem, most compiler writers use a different tool or tech- OMeta’s general-purpose pattern matching provides a nat- nique (e.g., lex, yacc, and the visitor design pattern [6]) to ural and convenient way for programmers to implement implement each compilation phase. As a result, the skill of tokenizers, parsers, visitors, and tree transformers, all of programming language implementation has a steep learning which can be extended in interesting ways using familiar curve (because one must learn how to use a number of dif- object-oriented mechanisms. This makes OMeta particularly ferent tools) and is not widely understood. well-suited as a medium for experimenting with new designs Several popular programming languages—ML, for in- for programming languages and extensions to existing lan- stance—include support for pattern matching. Unfortu- guages. nately, while ML-style pattern matching is a great tool for processing structured data, it is not expressive enough on its Categories and Subject Descriptors D.1.5 [Programming own to support more complex pattern matching tasks such Techniques]: Object-Oriented Programming; D.3.3 [Pro- as lexical analysis and parsing. gramming Languages]: Language Constructs and Features Perhaps by providing programming language support for a more general form of pattern matching, many useful tech- General Terms Design, Languages niques such as parsing—a skill more or less exclusive to Keywords pattern matching, parsing, metacircular imple- “programming languages people”—might become part of mentation the skill-set of a much wider audience of programmers. (Consider how many Unix applications could be improved 1. Introduction if suddenly their implementors had the ability to process more interesting configuration files!) This is not to say that Many problems in computer science, especially in program- general-purpose pattern matching is likely to subsume spe- ming language implementation, involve some form of pat- cialized tools such as parser generators; that would be diffi- tern matching. Lexical analysis, for example, consists of cult to do, especially in terms of performance. But as we will finding patterns in a stream of characters to produce a stream show with various examples, general-purpose pattern match- of tokens. Similarly, a parser matches a stream of tokens ing provides a natural and convenient way to implement tok- enizers, parsers, visitors, and tree transformers, which makes ∗ This material is based upon work supported by the National Science Foun- dation under Grant No. 0639876. Any opinions, findings, and conclusions it an unrivaled tool for rapid prototyping. or recommendations expressed in this material are those of the authors and This work builds on Parsing Expression Grammars (PEGs) do not necessarily reflect the views of the National Science Foundation. [5] (a recognition-based foundation for describing syntax) as a basis for general-purpose pattern matching, and makes the following technical contributions: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute 1. a generalization of PEGs that can handle arbitrary kinds to lists, requires prior specific permission and/or a fee. DLS’07, October 22, 2007, Montreal,´ Quebec,´ Canada. of data (i.e., not just streams of characters) and supports Copyright c 2007 ACM 978-1-59593-868-8/07/0010. $5.00 ! parameterized and higher-order productions (Section 2), expression meaning meta E { e1 e2 sequencing dig ::= ’0’ | ... | ’9’; e1 | e2 prioritized choice num ::= <dig>+; e∗ zero or more repetitions fac ::= <fac> ’*’ <num> e+ one or more repetitions (not essential) | <fac> ’/’ <num> e negation | <num>; <∼p> production application exp ::= <exp> ’+’ <fac> ’x’ matches the character x | <exp> ’-’ <fac> | <fac>; Table 1. Inductive definition of the language of parsing ex- } pressions (assumes that e, e , and e are parsing expressions, 1 2 Figure 1. A PEG, written in OMeta, that recognizes simple and that p is a non-terminal). arithmetic expressions. 2. a simple yet powerful extensibility mechanism for PEGs Semantic actions are specified using the => operator and (Section 3), written in OMeta’s host language, which is usually the 3. the design and implementation of OMeta, a programming language in which the OMeta implementation was writ- language with convenient BNF-like syntax that embodies ten. We currently have two implementations: one written 2 (1) and (2), and in COLA [11], and another in Squeak Smalltalk , both of which can be downloaded from http://www.cs.ucla. 4. a series of examples that demonstrate how our general- edu/ awarth/ometa/. purpose pattern matching facilities may be used in the ∼ domain of programming language implementation. Important: All of the examples in this paper were writ- The rest of this paper explores our notion of general-purpose ten for the COLA implementation of OMeta; if you are pattern matching in the context of OMeta. not familiar with COLA, try to think of it as a cross be- tween Scheme and Smalltalk. 2. OMeta: an extended PEG The syntax of the functional parts of the language is very An OMeta program is a Parsing Expression Grammar (PEG) similar to Scheme, e.g., (+ 1 2 (f 5)). that can make use of a number of extensions in order to han- dle arbitrary kinds of data (PEGs are limited to processing COLA message sends look similar to Smalltalk’s, but are streams of characters). This section begins by introducing written in square brackets, e.g., [jimmy eat: banana]. the features that OMeta and PEGs have in common, and then Note that each []-expression represents a single message describes some of OMeta’s extensions to PEGs. send; the COLA translation of the Smalltalk message Array new: x size is [Array new: [x size]]. 2.1 PEGs, OMeta Style Refer to http://piumarta.com/pepsi/coke.html Parsing Expression Grammars (PEGs) [5] are a recognition- for a more detailed description of COLA syntax. based foundation for describing syntax. A PEG is a collec- tion of productions of the form non-terminal parsing- expression; the language of parsing expressions→is shown in Here is one way our grammar’s exp production might be Table 1. modified in order to create parse trees (the other productions To avoid ambiguities that arise from using a non-de- in our grammar would have to be modified accordingly): terministic choice operator (the kind of choice found in exp ::= <exp>:x ’+’ <fac>:y => ‘(+ ,x ,y) CFGs), PEGs only support prioritized choice. In other | <exp>:x ’-’ <fac>:y => ‘(- ,x ,y) words, choices are always evaluated in order. As a result, | <fac>; there is no such thing as an ambiguous PEG, and their be- havior is easy to understand.1 Note that the results of <exp> and <fac> are bound to iden- Figure 1 shows a PEG, written in OMeta syntax, that tifiers (with the : operator) and referenced by the seman- recognizes simple arithmetic expressions (it does not cre- tic actions to create parse tree nodes. Note also that the last ate parse trees). In order to create parse tree nodes and/or choice in this production, <fac>, does not specify a seman- do anything else upon successful matches, the programmer tic action. In the absence of a semantic action, the value re- must write semantic actions. turned by a production upon a successful match is the result of the last expression evaluated (hence <fac> is equivalent 1 Although the use of left-recursive productions should result in infinite re- to <fac>:x => x). cursion (because of prioritized choice), some PEG implementations, includ- ing OMeta, provide special support for left recursion as a convenience. 2 The Squeak port of OMeta was joint work with Yoshiki Ohshima. OMeta has a single built-in production from which every 2.3 PEG Extensions for Expressiveness other production is derived. The name of this production is OMeta’s productions, unlike those in PEGs, may take any (underscore), and it consumes exactly one element from the number of arguments. This feature can be used to imple- input stream. Even the end production, which detects the ment a lot of functionality that would otherwise have to be end of the input stream, is implemented in terms of : built into the language. As an example, consider regular- end ::= ~<_>; expression-style character classes, which traditional PEG implementations support in order to spare programmers In other words, we are at the end of the input stream if from the tedious and error-prone job of writing productions it is not possible to consume another element from it. As such as noted in [5], the ~ operator—used for negation—can also be used to provide unlimited look-ahead capability.
Load more

Recommended publications
  • Adaptive LL(*) Parsing: the Power of Dynamic Analysis
    Adaptive LL(*) Parsing: The Power of Dynamic Analysis Terence Parr Sam Harwell Kathleen Fisher University of San Francisco University of Texas at Austin Tufts University [email protected] [email protected] kfi[email protected] Abstract PEGs are unambiguous by definition but have a quirk where Despite the advances made by modern parsing strategies such rule A ! a j ab (meaning “A matches either a or ab”) can never as PEG, LL(*), GLR, and GLL, parsing is not a solved prob- match ab since PEGs choose the first alternative that matches lem. Existing approaches suffer from a number of weaknesses, a prefix of the remaining input. Nested backtracking makes de- including difficulties supporting side-effecting embedded ac- bugging PEGs difficult. tions, slow and/or unpredictable performance, and counter- Second, side-effecting programmer-supplied actions (muta- intuitive matching strategies. This paper introduces the ALL(*) tors) like print statements should be avoided in any strategy that parsing strategy that combines the simplicity, efficiency, and continuously speculates (PEG) or supports multiple interpreta- predictability of conventional top-down LL(k) parsers with the tions of the input (GLL and GLR) because such actions may power of a GLR-like mechanism to make parsing decisions. never really take place [17]. (Though DParser [24] supports The critical innovation is to move grammar analysis to parse- “final” actions when the programmer is certain a reduction is time, which lets ALL(*) handle any non-left-recursive context- part of an unambiguous final parse.) Without side effects, ac- free grammar. ALL(*) is O(n4) in theory but consistently per- tions must buffer data for all interpretations in immutable data forms linearly on grammars used in practice, outperforming structures or provide undo actions.
    [Show full text]
  • Disambiguation Filters for Scannerless Generalized LR Parsers
    Disambiguation Filters for Scannerless Generalized LR Parsers Mark G. J. van den Brand1,4, Jeroen Scheerder2, Jurgen J. Vinju1, and Eelco Visser3 1 Centrum voor Wiskunde en Informatica (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands {Mark.van.den.Brand,Jurgen.Vinju}@cwi.nl 2 Department of Philosophy, Utrecht University Heidelberglaan 8, 3584 CS Utrecht, The Netherlands [email protected] 3 Institute of Information and Computing Sciences, Utrecht University P.O. Box 80089, 3508TB Utrecht, The Netherlands [email protected] 4 LORIA-INRIA 615 rue du Jardin Botanique, BP 101, F-54602 Villers-l`es-Nancy Cedex, France Abstract. In this paper we present the fusion of generalized LR pars- ing and scannerless parsing. This combination supports syntax defini- tions in which all aspects (lexical and context-free) of the syntax of a language are defined explicitly in one formalism. Furthermore, there are no restrictions on the class of grammars, thus allowing a natural syntax tree structure. Ambiguities that arise through the use of unrestricted grammars are handled by explicit disambiguation constructs, instead of implicit defaults that are taken by traditional scanner and parser gener- ators. Hence, a syntax definition becomes a full declarative description of a language. Scannerless generalized LR parsing is a viable technique that has been applied in various industrial and academic projects. 1 Introduction Since the introduction of efficient deterministic parsing techniques, parsing is considered a closed topic for research, both by computer scientists and by practi- cioners in compiler construction. Tools based on deterministic parsing algorithms such as LEX & YACC [15,11] (LALR) and JavaCC (recursive descent), are con- sidered adequate for dealing with almost all modern (programming) languages.
    [Show full text]
  • Introduction to Programming Languages and Syntax
    Programming Languages Session 1 – Main Theme Programming Languages Overview & Syntax Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Adapted from course textbook resources Programming Language Pragmatics (3rd Edition) Michael L. Scott, Copyright © 2009 Elsevier 1 Agenda 11 InstructorInstructor andand CourseCourse IntroductionIntroduction 22 IntroductionIntroduction toto ProgrammingProgramming LanguagesLanguages 33 ProgrammingProgramming LanguageLanguage SyntaxSyntax 44 ConclusionConclusion 2 Who am I? - Profile - ¾ 27 years of experience in the Information Technology Industry, including thirteen years of experience working for leading IT consulting firms such as Computer Sciences Corporation ¾ PhD in Computer Science from University of Colorado at Boulder ¾ Past CEO and CTO ¾ Held senior management and technical leadership roles in many large IT Strategy and Modernization projects for fortune 500 corporations in the insurance, banking, investment banking, pharmaceutical, retail, and information management industries ¾ Contributed to several high-profile ARPA and NSF research projects ¾ Played an active role as a member of the OMG, ODMG, and X3H2 standards committees and as a Professor of Computer Science at Columbia initially and New York University since 1997 ¾ Proven record of delivering business solutions on time and on budget ¾ Original designer and developer of jcrew.com and the suite of products now known as IBM InfoSphere DataStage ¾ Creator of the Enterprise
    [Show full text]
  • Packrat Parsing: Simple, Powerful, Lazy, Linear Time
    Packrat Parsing: Simple, Powerful, Lazy, Linear Time Functional Pearl Bryan Ford Massachusetts Institute of Technology Cambridge, MA [email protected] Abstract 1 Introduction Packrat parsing is a novel technique for implementing parsers in a There are many ways to implement a parser in a functional pro- lazy functional programming language. A packrat parser provides gramming language. The simplest and most direct approach is the power and flexibility of top-down parsing with backtracking and top-down or recursive descent parsing, in which the components unlimited lookahead, but nevertheless guarantees linear parse time. of a language grammar are translated more-or-less directly into a Any language defined by an LL(k) or LR(k) grammar can be rec- set of mutually recursive functions. Top-down parsers can in turn ognized by a packrat parser, in addition to many languages that be divided into two categories. Predictive parsers attempt to pre- conventional linear-time algorithms do not support. This additional dict what type of language construct to expect at a given point by power simplifies the handling of common syntactic idioms such as “looking ahead” a limited number of symbols in the input stream. the widespread but troublesome longest-match rule, enables the use Backtracking parsers instead make decisions speculatively by try- of sophisticated disambiguation strategies such as syntactic and se- ing different alternatives in succession: if one alternative fails to mantic predicates, provides better grammar composition properties, match, then the parser “backtracks” to the original input position and allows lexical analysis to be integrated seamlessly into parsing. and tries another.
    [Show full text]
  • Compiler Construction
    Compiler construction PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 10 Dec 2011 02:23:02 UTC Contents Articles Introduction 1 Compiler construction 1 Compiler 2 Interpreter 10 History of compiler writing 14 Lexical analysis 22 Lexical analysis 22 Regular expression 26 Regular expression examples 37 Finite-state machine 41 Preprocessor 51 Syntactic analysis 54 Parsing 54 Lookahead 58 Symbol table 61 Abstract syntax 63 Abstract syntax tree 64 Context-free grammar 65 Terminal and nonterminal symbols 77 Left recursion 79 Backus–Naur Form 83 Extended Backus–Naur Form 86 TBNF 91 Top-down parsing 91 Recursive descent parser 93 Tail recursive parser 98 Parsing expression grammar 100 LL parser 106 LR parser 114 Parsing table 123 Simple LR parser 125 Canonical LR parser 127 GLR parser 129 LALR parser 130 Recursive ascent parser 133 Parser combinator 140 Bottom-up parsing 143 Chomsky normal form 148 CYK algorithm 150 Simple precedence grammar 153 Simple precedence parser 154 Operator-precedence grammar 156 Operator-precedence parser 159 Shunting-yard algorithm 163 Chart parser 173 Earley parser 174 The lexer hack 178 Scannerless parsing 180 Semantic analysis 182 Attribute grammar 182 L-attributed grammar 184 LR-attributed grammar 185 S-attributed grammar 185 ECLR-attributed grammar 186 Intermediate language 186 Control flow graph 188 Basic block 190 Call graph 192 Data-flow analysis 195 Use-define chain 201 Live variable analysis 204 Reaching definition 206 Three address
    [Show full text]
  • Incremental Scannerless Generalized LR Parsing
    SPLASH: G: Incremental Scannerless Generalized LR Parsing Maarten P. Sijm Delft University of Technology Delft, The Netherlands [email protected] Abstract a separate lexing (or scanning) phase, supports modelling We present the Incremental Scannerless Generalized LR the entire language syntax in one single grammar, and al- (ISGLR) parsing algorithm, which combines the benefits of lows composition of grammars for different languages. One Incremental Generalized LR (IGLR) parsing and Scanner- notable disadvantage is that the SGLR parsing algorithm of less Generalized LR (SGLR) parsing. The ISGLR parser can Visser [9] is a batch algorithm, meaning that it must process reuse parse trees from unchanged regions in the input and each entire file in one pass. This becomes a problem for soft- thus only needs to parse changed regions. We also present ware projects that have large files, as every small change incremental techniques for imploding the parse tree to an requires the entire file to be parsed again. Abstract Syntax Tree (AST) and syntax highlighting. Scan- Incremental Generalized LR (IGLR) parsing is an improve- nerless parsing relies heavily on non-determinism during ment over batch Generalized LR (GLR) parsing. Amongst parsing, negatively impacting the incrementality of ISGLR others, Wagner [10] and TreeSitter [8] have created parsing parsing. We evaluated the ISGLR parsing algorithm using algorithms that allow rapid parsing of changes to large files. file histories from Git, achieving a speedup of up to 25 times However, these algorithms use a separate incremental lexical over non-incremental SGLR. analysis phase which complicates the implementation of in- cremental parsing [11] and does not directly allow language CCS Concepts • Software and its engineering → Incre- composition.
    [Show full text]
  • Faster Scannerless GLR Parsing
    Faster Scannerless GLR Parsing Giorgios Economopoulos, Paul Klint, Jurgen Vinju Centrum voor Wiskunde en Informatica (CWI), Kruislaan 413, 1098 SJ Amsterdam, The Netherlands Abstract. Analysis and renovation of large software portfolios requires syntax analysis of multiple, usually embedded, languages and this is be- yond the capabilities of many standard parsing techniques. The tradi- tional separation between lexer and parser falls short due to the limita- tions of tokenization based on regular expressions when handling multiple lexical grammars. In such cases scannerless parsing provides a viable so- lution. It uses the power of context-free grammars to be able to deal with a wide variety of issues in parsing lexical syntax. However, it comes at the price of less efficiency. The structure of tokens is obtained using a more powerful but more time and memory intensive parsing algorithm. Scan- nerless grammars are also more non-deterministic than their tokenized counterparts, increasing the burden on the parsing algorithm even fur- ther. In this paper we investigate the application of the Right-Nulled Gener- alized LR parsing algorithm (RNGLR) to scannerless parsing. We adapt the Scannerless Generalized LR parsing and filtering algorithm (SGLR) to implement the optimizations of RNGLR. We present an updated pars- ing and filtering algorithm, called SRNGLR, and analyze its performance in comparison to SGLR on ambiguous grammars for the programming languages C, Java, Python, SASL, and C++. Measurements show that SRNGLR is on average 33% faster than SGLR, but is 95% faster on the highly ambiguous SASL grammar. For the mainstream languages C, C++, Java and Python the average speedup is 16%.
    [Show full text]
  • Mining Structured Data in Natural Language Artifacts with Island Parsing
    Science of Computer Programming 150 (2017) 31–55 Contents lists available at ScienceDirect Science of Computer Programming www.elsevier.com/locate/scico Mining structured data in natural language artifacts with island parsing ∗ Alberto Bacchelli a, , Andrea Mocci b, Anthony Cleve c, Michele Lanza b a Department of Informatics, University of Zurich, Switzerland b REVEAL @ Software Institute, Università della Svizzera italiana (USI), Switzerland c Faculty of Informatics, University of Namur, Belgium a r t i c l e i n f o a b s t r a c t Article history: Software repositories typically store data composed of structured and unstructured Received 11 December 2015 parts. Researchers mine this data to empirically validate research ideas and to support Received in revised form 18 November 2016 practitioners’ activities. Structured data (e.g., source code) has a formal syntax and is Accepted 13 June 2017 straightforward to analyze; unstructured data (e.g., documentation) is a mix of natural Available online 1 August 2017 language, noise, and snippets of structured data, and it is harder to analyze. Especially Keywords: the structured content (e.g., code snippets) in unstructured data contains valuable Mining software repositories information. Unstructured data Researchers have proposed several approaches to recognize, extract, and analyze structured Island parsing data embedded in natural language. We analyze these approaches and investigate their drawbacks. Subsequently, we present two novel methods, based on scannerless generalized LR (SGLR) and Parsing Expression Grammars (PEGs), to address these drawbacks and to mine structured fragments within unstructured data. We validate and compare these approaches on development emails and Stack Overflow posts with Java code fragments.
    [Show full text]
  • LNCS 9031, Pp
    Faster, Practical GLL Parsing Ali Afroozeh and Anastasia Izmaylova Centrum Wiskunde & Informatica, 1098 XG Amsterdam, The Netherlands {ali.afroozeh, anastasia.izmaylova}@cwi.nl Abstract. Generalized LL (GLL) parsing is an extension of recursive- descent (RD) parsing that supports all context-free grammars in cubic time and space. GLL parsers have the direct relationship with the gram- mar that RD parsers have, and therefore, compared to GLR, are easier to understand, debug, and extend. This makes GLL parsing attractive for parsing programming languages. In this paper we propose a more efficient Graph-Structured Stack (GSS) for GLL parsing that leads to significant performance improve- ment. We also discuss a number of optimizations that further improve the performance of GLL. Finally, for practical scannerless parsing of pro- gramming languages, we show how common lexical disambiguation filters canbeintegratedinGLLparsing. Our new formulation of GLL parsing is implemented as part of the Iguana parsing framework. We evaluate the effectiveness of our approach using a highly-ambiguous grammar and grammars of real programming languages. Our results, compared to the original GLL, show a speedup factor of 10 on the highly-ambiguous grammar, and a speedup factor of 1.5, 1.7, and 5.2 on the grammars of Java, C#, and OCaml, respectively. 1 Introduction Developing efficient parsers for programming languages is a difficult task that is usually automated by a parser generator. Since Knuth’s seminal paper [1] on LR parsing, and DeRemer’s work on practical LR parsing (LALR) [2], parsers of many major programming languages have been constructed using LALR parser generators such as Yacc [3].
    [Show full text]
  • Chapter 5 Disambiguation Strategies
    Eindhoven University of Technology MASTER Disambiguation mechanisms and disambiguation strategies ten Brink, A.P. Award date: 2013 Link to publication Disclaimer This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required minimum study period may vary in duration. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain Department of Mathematics and Computer Science Den Dolech 2, 5612 AZ Eindhoven P.O. Box 513, 5600 MB Eindhoven The Netherlands www.tue.nl Supervisor prof. dr. Mark van den Brand (TU/e) Disambiguation mechanisms and Section disambiguation strategies Model Driven Software Engineering Date August 23, 2013 Master’s Thesis Alex P. ten Brink Where innovation starts Abstract It is common practice for engineers to express artifacts such as domain specific languages using ambiguous context-free grammars along with separate disambiguation rules, rather than to use equivalent unambiguous context-free grammars, as these ambiguous grammars often capture the intent of the engineer more directly.
    [Show full text]
  • One Parser to Rule Them All
    One Parser to Rule Them All Ali Afroozeh Anastasia Izmaylova Centrum Wiskunde & Informatica, Amsterdam, The Netherlands {ali.afroozeh, anastasia.izmaylova}@cwi.nl Abstract 1. Introduction Despite the long history of research in parsing, constructing Parsing is a well-researched topic in computer science, and parsers for real programming languages remains a difficult it is common to hear from fellow researchers in the field and painful task. In the last decades, different parser gen- of programming languages that parsing is a solved prob- erators emerged to allow the construction of parsers from a lem. This statement mostly originates from the success of BNF-like specification. However, still today, many parsers Yacc [18] and its underlying theory that has been developed are handwritten, or are only partly generated, and include in the 70s. Since Knuth’s seminal paper on LR parsing [25], various hacks to deal with different peculiarities in program- and DeRemer’s work on practical LR parsing (LALR) [6], ming languages. The main problem is that current declara- there is a linear parsing technique that covers most syntactic tive syntax definition techniques are based on pure context- constructs in programming languages. Yacc, and its various free grammars, while many constructs found in program- ports to other languages, enabled the generation of efficient ming languages require context information. parsers from a BNF specification. Still, research papers and In this paper we propose a parsing framework that em- tools on parsing in the last four decades show an ongoing braces context information in its core. Our framework is effort to develop new parsing techniques.
    [Show full text]
  • Semantics and Algorithms for Data-Dependent Grammars
    Semantics and Algorithms for Data-dependent Grammars Trevor Jim Yitzhak Mandelbaum David Walker AT&T Labs-Research AT&T Labs-Research Princeton University [email protected] [email protected] [email protected] Abstract ern times, programmer convenience and expressiveness were sacri- Traditional parser generation technologies are incapable of han- ficed for performance. Since then, for the most part, PL researchers dling the demands of modern programmers. In this paper, we have hung on to legacy tools because they are well-known, well- supported, taught in school and universally available, rather than present the design and theory of a new parsing engine, YAKKER, capable of handling the requirements of modern applications in- because they are optimally designed. cluding (1) full scannerless context-free grammars with (2) reg- On the other hand, programmers outside the minuscule world ular expressions as right-hand sides for defining nonterminals. of PL implementors almost never use parser generators. Despite the fact that they are constantly writing parsers—for data formats, YAKKER also includes (3) facilities for binding variables to in- termediate parse results and (4) using such bindings within arbi- networking protocols, configuration files, web scraping and small trary constraints to control parsing. These facilities allow the kind domain-specific languages—they do most of it by hand, often us- of data-dependent parsing commonly needed in systems applica- ing regular expression libraries that support context-sensitive fea- tions, particularly those that operate over binary data. In addition, tures like backreferencing and POSIX anchors. This is not because (5) nonterminals may be parameterized by arbitrary values, which they are unaware of PL tools, but rather because these tools do not gives the system good modularity and abstraction properties in the solve their problems.
    [Show full text]