Visitors unchained

Pottier, François

doi:10.1145/3110272

Cited by 5 publications

(4 citation statements)

References 37 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…OCaml's abstract syntax data type contains source code location information, which we used to produce accurate patches describing how to apply the renaming. We also relied on the recently developed visitors library [35] to automatically generate boilerplate code for traversing and processing the abstract syntax trees. This library provides similar functionality to that found in Haskell's SYB [18] and Strafunski [19] libraries, or the Stratego/XT framework [10].…”

Section: Methodsmentioning

confidence: 99%

Characterising renaming within OCaml’s module system: theory and implementation

Rowe

Férée

Thompson

et al. 2019

Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation

View full text Add to dashboard Cite

We present an abstract, set-theoretic denotational semantics for a signiicant subset of OCaml and its module system in order to reason about the correctness of renaming value bindings. Our abstract semantics captures information about the binding structure of programs. Crucially for renaming, it also captures information about the relatedness of diferent declarations that is induced by the use of various diferent language constructs (e.g. functors, module types and module constraints). Correct renamings are precisely those that preserve this structure. We demonstrate that our semantics allows us to prove various high-level, intuitive properties of renamings. We also show that it is sound with respect to a (domain-theoretic) denotational model of the operational behaviour of programs. This formal framework has been implemented in a prototype refactoring tool for OCaml that performs renaming. module type Stringable = sig type t val to_string : t -> string end module Pair(X : Stringable)(Y : Stringable) = struct type t = X.t * Y.t let to_string (x, y) = (X.to_string x)^" "^(Y.to_string y) end module Int = struct type t = int let to_string i = int_to_string i end module String = struct type t = string let to_string s = s end module P = Pair(Int)(Pair(String)(Int)) ;; print_endline (P.to_string (0, ("!=", 1))) ;;Characterising Renaming within OCaml's Module System PLDI '19, June 22ś26, 2019, Phoenix, AZ, USA While the paper describes the work in the context of OCaml modules, the approach can be used to understand aspects of (re)naming in other languages, such as Haskell (classes and instances), and Java (interfaces).

show abstract

Section: Methodsmentioning

confidence: 99%

Characterising renaming within OCaml’s module system: theory and implementation

Rowe

Férée

Thompson

et al. 2019

Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation

View full text Add to dashboard Cite

show abstract

“…In the API, six classes of visitors are provided: iter to traverse a CST, map to transform a CST into another CST, reduce to compute a value by a bottom-up recursive computation on a CST, as well as iter2, map2 and reduce2 which traverse two input CSTs of similar shapes at the same time. These visitors come for free as we use a preprocessor [20] which automatically generates visitors classes out of type definitions.…”

Section: Shell Parsing Toolkitmentioning

confidence: 99%

Morbig: A Static parser for POSIX shell

Régis-Gianas

Jeannerod

Treinen

2020

Journal of Computer Languages

View full text Add to dashboard Cite

The POSIX shell language defies conventional wisdom of compiler construction on several levels: The shell language was not designed for static parsing, but with an intertwining of syntactic analysis and execution by expansion in mind. Token recognition cannot be specified by regular expressions, lexical analysis depends on the parsing context and the evaluation context, and the shell grammar given in the specification is ambiguous. Besides, the unorthodox design choices of the shell language fit badly in the usual specification languages used to describe other programming languages. This makes the standard usage of Lex and Yacc as a pipeline inadequate for the implementation of a parser for POSIX shell. The existing implementations of shell parsers are complex and use low-level character-level parsing code which is difficult to relate to the POSIX specification. We find it hard to trust such parsers, especially when using them for writing automatic verification tools for shell scripts.This paper offers an overview of the technical difficulties related to the syntactic analysis of the POSIX shell language. It also describes how we have resolved these difficulties using advanced parsing techniques (namely speculative parsing, parser state introspection, context-dependent lexical analysis and longest-prefix parsing) while keeping the implementation at a sufficiently high level of abstraction so that experts can check that the POSIX standard is respected. The resulting tool, called Morbig, is an open-source static parser for a well-defined and realistic subset of the POSIX shell language.

show abstract

“…The core of ROTOR's operation involves performing various kinds of traversals over the program's abstract syntax trees. For this, we have made use of the recently developed visitors syntax extension for OCaml [9]. This automatically generates classes whose methods perform a bottom-up traversal of values of a given set of datatypes.…”

Section: Use Of Visitor Classesmentioning

confidence: 99%