1 / 1

InterpreterLib: A Library for Building Modular,

InterpreterLib: A Library for Building Modular, Extensible, and Composable Interpreters Systems Level Design Group (pweaver@ittc.ku.edu). Motivation. Background. Functors A functor is a type constructor f over which fmap is defined fmap :: (a -> b) -> f a -> f b

lamar
Télécharger la présentation

InterpreterLib: A Library for Building Modular,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. InterpreterLib: A Library for Building Modular, Extensible, and Composable InterpretersSystems Level Design Group (pweaver@ittc.ku.edu) Motivation Background • Functors • A functor is a type constructor f over which fmap is defined • fmap :: (a -> b) -> f a -> f b • Terms in an AST are functors, over which an evaluation • function can be mapped • Recursion Scheme • Interpreters typically follow a regular recursion scheme • All term arguments are evaluated first: • eval (Val n) = n • eval (Add term1 term2) = eval tm1 + eval tm2 • Can be generalized by folding a function, phi, over an AST: • phi (Val n) = n • phi (Add term1 term2) = term1 + term2 • eval = fold phi • Algebras • An Algebra defines a phi function for a particular language • Define a language as a combination of sub-languages. • Write an algebra for each sub-language. • Combine algebras to form an interpreter for the language • Modularity and Extensibilty • Interpreters should be made up of individual components • Components should be separate and should not depend • on each other • Components and features should be easy to add, without • requiring changes to other components in the interpreter • Executability • Interpreters should be executable • Interpreters written with InterpreterLib can be compiled • by ghc and executed • Provability • Programmer should be able to prove properties of • interpreters more easily, without manual induction • Abstraction • Lower-level details should be hidden from programmer • Haskell monads and InterpreterLib provide excellent • abstraction, doing a lot of work for the programmer! Details Example: SAFL to SECD • Fixed Points • A way to define recursive data structures non-recursively • newtype Fix f = In (f (Fix f)) • out (In x) = x • Catamorhpism • Folding is captured and generalized by a catamorphism • cata = phi ° fmap cata ° out • Inductive properties of a catamorphism are “free” • Algebra Compiler • User simply defines signature of language • ALGC generates haskell code for AST elements:: • Data structures for terms (functors) • Functions to build terms • Definition of fmap over the terms • Functions to generate algebras from phi functions • Future Work • Improvements to algebra compiler • Handle non-regular recursion schemes • Implement paramorphisms and anamorphism • Tool-chain written in InterpreterLib transforms a SAFL program to an SECD machine • Parser parses SAFL into an abstract syntax tree • Type checker and interpreter yield the types and values associated with AST elements • Type directed partial evaluator reifies the values to yield a normalized, partially evaluated AST • SAFL compiler transforms the AST into code for the SECD abstract machine and optionally synthesizes a netlist.

More Related