Refactoring Haskell Programs Huiqing Li Computing Lab, University of Kent www.cs.kent.ac.uk/projects/refactor-fp/

Slides:



Advertisements
Similar presentations
HaRe The Haskell Refactorer Huiqing Li Claus Reinke Simon Thompson Computing Lab, University of Kent
Advertisements

Tool Support for Refactoring Functional Programs Huiqing Li Claus Reinke Simon Thompson Computing Lab, University of Kent
Progress on ‘HaRe: The Haskell Refactorer’ Huiqing Li, Claus Reinke, Simon Thompson Computing Laboratory, University of Kent Refactoring is the process.
1 1 Regression Verification for Multi-Threaded Programs Sagar Chaki, SEI-Pittsburgh Arie Gurfinkel, SEI-Pittsburgh Ofer Strichman, Technion-Haifa Originally.
1 Programming Languages (CS 550) Lecture Summary Functional Programming and Operational Semantics for Scheme Jeremy R. Johnson.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
C. Varela; Adapted w/permission from S. Haridi and P. Van Roy1 Declarative Computation Model Defining practical programming languages Carlos Varela RPI.
1 Semantic Processing. 2 Contents Introduction Introduction A Simple Compiler A Simple Compiler Scanning – Theory and Practice Scanning – Theory and Practice.
The Formalisation of Haskell Refactorings Huiqing Li Simon Thompson Computing Lab, University of Kent
Syntax With Binders COS 441 Princeton University Fall 2004.
WRT 2007 Refactoring Functional Programs Huiqing Li Simon Thompson Computing Lab Chris Brown Claus Reinke University of Kent.
The Haskell Refactorer, HaRe, and its API Huiqing Li Claus Reinke Simon Thompson Computing Lab, University of Kent
Describing Syntax and Semantics
Generative Programming. Generic vs Generative Generic Programming focuses on representing families of domain concepts Generic Programming focuses on representing.
Refactoring Functional Programs Huiqing Li Claus Reinke Simon Thompson Computing Lab, University of Kent.
PPL Syntax & Formal Semantics Lecture Notes: Chapter 2.
PPL Syntax & Formal Semantics Lecture Notes: Chapter 2.
Extreme Grammaring Development of an industrial strength ISO VDM-SL Grammar.
An Approach and Tool for Synchronous Refactoring of UML Diagrams and Models Using Model-to-Model Transformations Hafsteinn Þór Einarsson Helmut Neukirchen.
C++ Code Analysis: an Open Architecture for the Verification of Coding Rules Paolo Tonella ITC-irst, Centro per la Ricerca Scientifica e Tecnologica
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
Comp 311 Principles of Programming Languages Lecture 1 Course Overview and Culture Corky Cartwright August 25, 2008.
Chapter 1 Introduction Dr. Frank Lee. 1.1 Why Study Compiler? To write more efficient code in a high-level language To provide solid foundation in parsing.
DIY Refactorings in Wrangler Huiqing Li Simon Thompson School of Computing University of Kent.
Functional Programming Universitatea Politehnica Bucuresti Adina Magda Florea
Lambda Calculus History and Syntax. History The lambda calculus is a formal system designed to investigate function definition, function application and.
1 COMP313A Functional Programming (1). 2 Main Differences with Imperative Languages Say more about what is computed as opposed to how Pure functional.
WSMX Execution Semantics Executable Software Specification Eyal Oren DERI
Supported by ELTE IKKK, Ericsson Hungary, in cooperation with University of Kent Erlang refactoring with relational database Anikó Víg and Tamás Nagy Supervisors:
A Theory of Hygienic Macros David Herman, Mitchell Wand Northeastern University.
Chapter 7 System models.
Generative Programming. Automated Assembly Lines.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IX Interpreter, Mediator, Template Method recap.
Supported by ELTE IKKK, Ericsson Hungary, in cooperation with University of Kent Erlang refactoring with relational database Anikó Víg and Tamás Nagy Supervisors:
1 ML fun x -> e e 1 e 2 0, 1, 2,..., +, -,... true, false, if e then e else e patterns datatypes exceptions structures functors let f x = e variables These.
Modeling Component-based Software Systems with UML 2.0 George T. Edwards Jaiganesh Balasubramanian Arvind S. Krishna Vanderbilt University Nashville, TN.
Refactoring Erlang Programs Huiqing Li Simon Thompson University of Kent Zoltán Horváth Eötvös Loránd Univ.
COP 4620 / 5625 Programming Language Translation / Compiler Writing Fall 2003 Lecture 1, 08/28/03 Prof. Roy Levow.
Stratego Song Zhou *Include slides from language.org/Stratego/SlidesForSoftwareGeneration2001http:// language.org/Stratego/SlidesForSoftwareGeneration2001.
COMP313A Functional Programming (1)
CSE-321 Programming Languages -Calculus (II) POSTECH March 27, 2006 박성우.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor.
1 JTransformer Framework Tobias Windeln Institut für Informatik III Rheinische Friedrich-Wilhelms-Universität Bonn.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
-Calculus Kangwon National University 임현승 Programming Languages These slides are based on the slides by Prof. Sungwoo Park at POSTECH.
Lambda Calculus CSE 340 – Principles of Programming Languages Fall 2015 Adam Doupé Arizona State University
Scalable Clone Detection and Elimination for Erlang Programs Huiqing Li, Simon Thompson University of Kent Canterbury, UK.
The Interpreter Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Review of Parnas’ Criteria for Decomposing Systems into Modules Zheng Wang, Yuan Zhang Michigan State University 04/19/2002.
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
FUNCTIONAL PROGRAMING AT WORK - HASKELL AND DOMAIN SPECIFIC LANGUAGES Dr. John Peterson Western State Colorado University.
CSE-321 Programming Languages -Calculus (II) POSTECH March 26, 2007 박성우.
PPL Syntax & Formal Semantics Lecture Notes: Chapter 2.
Arvind Computer Science and Artificial Intelligence Laboratory M.I.T. L03-1 September 14, 2006http:// -calculus: A Basis for.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Functional Programming
Lambda Calculus CSE 340 – Principles of Programming Languages
Introduction to Parsing (adapted from CS 164 at Berkeley)
Interpreters Study Semantics of Programming Languages through interpreters (Executable Specifications) cs7100(Prasad) L8Interp.
CS 611: Lecture 9 More Lambda Calculus: Recursion, Scope, and Substitution September 17, 1999 Cornell University Computer Science Department Andrew Myers.
Presentation by Julie Betlach 7/02/2009
Basic Program Analysis: AST
Introduction to SysML v.2.0 Metamodel (KerML)
Logical architecture refinement
Implementing Language Extensions with Model Transformations
Background In his classic 1972 paper on definitional interpreters, John Reynolds introduced two key techniques: Continuation-passing style - Makes.
Implementing Language Extensions with Model Transformations
Functional Programming and Haskell
Functional Programming and Haskell
Presentation transcript:

Refactoring Haskell Programs Huiqing Li Computing Lab, University of Kent

21/06/2015TCS2 Outline Refactoring HaRe: The Haskell Refactorer Implementation of HaRe Formalisation of Haskell Refactorings Future Work

21/06/2015TCS3 Refactoring What? Changing the structure of existing code without changing its behaviour. module Main (main) where f z y = y : f z (y + z) main y = print $ f 1 10  module Main (main) where f y = y : f (y + 1) main = print $ f 10 Example:

21/06/2015TCS4 HaRe – The Haskell Refactorer A tool for refactoring Haskell 98 programs. Full Haskell 98 coverage. Driving concerns: usability and extensibility. Integrated with the two program editors: (X)Emacs and Vim. Preserves both comments and layout style of the source.

21/06/2015TCS5 HaRe – The Haskell Refactorer Implemented in Haskell, using Programatica’s frontends and Strafunski’s generic traversals. Programatica: a system implemented in Haskell for the development of high-assurance software in Haskell. Strafunski: A Haskell library for supporting generic programming in application areas that involve term traversals over large abstract syntaxes.

21/06/2015TCS6 Refactorings Implemented in HaRe Structural Refactorings Module Refactorings Data-Oriented Refactorings

21/06/2015TCS7 Refactorings Implemented in HaRe Structural Refactorings Generalise a definition module Main (main) where f y = y : f (y + 1) main = print $ f 10 module Main (main) where f z y = y : f z (y + z) main y = print $ f 1 10 

21/06/2015TCS8 Refactorings Implemented in HaRe Structural Refactorings (cont.) Rename an identifier Promote/demote a definition to widen/narrow its scope Delete an unused function Duplicate a definition Unfold a definition Introduce a definition to name an identified expression Add an argument to a function Remove an unused argument from a function

21/06/2015TCS9 Refactorings Implemented in HaRe Module Refactorings module Test (f) where f y = y : f (y + 1) module Main where import Test main = print $ f 10 module Test ( ) where module Main where import Test f y = y : f (y + 1) main = print $ f 10  Move a definition from one module to another module

21/06/2015TCS10 Refactorings Implemented in HaRe Module Refactorings (cont.) Clean the imports Make the used entities explicitly imported Add an item to the export list Remove an item from the export list

21/06/2015TCS11 Refactorings Implemented in HaRe Data-oriented Refactorings From concrete to abstract data-type (ADT), which is a composite refactoring built from a sequence of primitive refactorings.

21/06/2015TCS12 Refactorings Implemented in HaRe

21/06/2015TCS13 Refactorings Implemented in HaRe

21/06/2015TCS14 TS: token stream; AST: annotated abstract syntax tree; MI: module information; Programatica (lexer, parser, type checker, module analysis) TS AST + MI Program TS’ analysis and transformation using Strafunski (with DrIFT) AST’ extract program from token stream Program Implementation of HaRe

21/06/2015TCS15 The Architecture of HaRe Composite Refactorings Elementary Refactorings RefacUtils (HaRe_API) Programatica Strafunski (with DrIFT) RefacLocUtils

21/06/2015TCS16 Formalisation of Refactorings Advantages: Clarify the definition of refactorings in terms of side-conditions and transformations. Improve our confidence in the behaviour-preservation of refactorings. Guide the implementation of refactorings. Challenges: Haskell is a non-trivial language. Haskell does not have an officially defined semantics.

21/06/2015TCS17 Formalisation of Refactorings Our Strategy: Start from a simple language ( letrec ). Extend the language gradually to formalise more complex refactorings.

21/06/2015TCS18 Formalisation of Refactorings The specification of a refactoring contains four parts: The representation of the program before the refactorings, say P 1 The side-conditions for the refactoring. The representation of the program after the refactorings, say P 2. A proof showing that P 1 and P 2 have the same functionality under the side-conditions.

21/06/2015TCS19 Formalisation of Refactorings The -calculus with letrec ( letrec ) Syntax of letrec terms. E ::= x | x.E | E 1 E 2 | letrec D in E D ::=  | x i =E i | D, D Use the call-by-name semantics developed by Zena M. Ariola and Stefan Blom in the paper Lambda Calculi plus letrec.

21/06/2015TCS20 Formalisation of Generalisation Recall the example module Main (main) where f y = y : f (y + 1) main = print $ f 10 module Main (main) where f z y = y : f z (y + z) main = print $ f 1 10 

21/06/2015TCS21 Formalisation of Generalisation Formal definition of Generalisation using letrec Given the expression: Assume E is a sub-expression of E i, and E i = C[E]. letrec x 1 =E 1,..., x i =E i,..., x n =E n in E 0

21/06/2015TCS22 Formalisation of Generalisation Formal definition of Generalisation using letrec The condition for generalising the definition x i =E i on E is: x i  FV(E ) Æ 8 x, e: (x 2 FV(E ) Æ e 2 sub(E i, C) ) x 2 FV(e)) module Main (main) where f y = y : f (y + 1) main = print $ f 10

21/06/2015TCS23 Formalisation of Generalisation Formal definition of Generalisation using letrec The condition for generalising the definition x i =E i on E is: x i  FV(E ) Æ 8 x, e: (x 2 FV(E ) Æ e 2 sub(E i, C) ) x 2 FV(e)) module Main (main) where f y = y : f (y + 1) main = print $ f 10

21/06/2015TCS24 Formalisation of Generalisation Formal definition of Generalisation using letrec The condition for generalising the definition x i =E i on E is: x i  FV(E ) Æ 8 x, e: (x 2 FV(E ) Æ e 2 sub(E i, C) ) x 2 FV(e)) module Main (main) where f y = y : f (y + 1) main = print $ f 10 

21/06/2015TCS25 Formalisation of Generalisation Formal definition of Generalisation using letrec After generalisation, the original expression becomes: letrec x 1 = E 1 [x i := x i E],..., x i = z.C[z][x i :=x i z],..., x n = E n [x i := x i E] in E 0 [x i := x i E], where z is a fresh variable. module Main (main) where f z y = y : f z (y + z) main = print $ f 1 10 module Main (main) where f y = y : f (y + 1) main = print $ f 10 

21/06/2015TCS26 Formalisation of Generalisation Formal definition of Generalisation using letrec Proof. Decompose the transformation into a number of sub steps, if each sub step is behaviour-preserving, then the transformation is behaviour-preserving.

21/06/2015TCS27 Formalisation of Generalisation Step1: add definition x = z.C[z], where x and z are fresh variables, and C[E]=E i. module Main (main) where f y = y : f (y +1) x z y = y : f ( y + z) main = print $ f 10 letrec x 1 =E 1,..., x i =E i, x = z.C[z],..., x n =E n in E 0 Step 2: Replace E i with x E. (Note: E i = x E)

21/06/2015TCS28 Step 2: Replace E i with x E. (Note: E i = x E) module Main (main) where f y = x 1 y x z y = y : f ( y + z) main = print $ f 10 letrec x 1 =E 1,..., x i = x E, x = z.C[z],..., x n =E n in E 0 Step 3: Unfolding x i in the right-hand side of x. Formalisation of Generalisation

21/06/2015TCS29 Formalisation of Generalisation Step 3: Unfolding x i in the right-hand side of x. module Main (main) where f y = x 1 y x z y = y : x 1 ( y + z) main = print $ f 10 letrec x 1 =E 1,..., x i = x E, x = z.C[z] [x_i:= x E],..., x n =E n in E 0 Step 4: In the definition of x, replace E with z, and prove this does not change the semantics of x E.

21/06/2015TCS30 Formalisation of Generalisation Step 4: In the definition of x, replace E with z. and prove this does not change the semantics of x E. module Main (main) where f y = x 1 y x z y = y : x z ( y + z) main = print $ f 10 letrec x 1 =E 1,..., x i = x E, x = z.C[z] [x_i:= x z],..., x n =E n in E 0 Step 5: Unfolding the occurrences of x i.

21/06/2015TCS31 Formalisation of Generalisation Step 5: Unfolding the occurrences of x i. module Main (main) where f y = x 1 y x z y = y : x z ( y + z) main = print $ x 1 10 letrec x 1 =E 1 [x i := x E],..., x i = x E, x = z.C[z] [x i := x z],..., x n =E n [x i := x E] in E 0 [x i := x E] Step 6: Remove the definition of x i.

21/06/2015TCS32 Formalisation of Generalisation Step 6: Remove the definition of x i. module Main (main) where x z y = y : x z ( y + z) main = print $ x 1 10 letrec x 1 =E 1 [x i := x E],..., x = z.C[z] [x i := x z],..., x n =E n [x i := x E] in E 0 [x i := x E] Step 7: Rename x to x i and simplify the substitution.

21/06/2015TCS33 Formalisation of Generalisation module Main (main) where f z y = y : f z ( y + z) main = print $ f 1 10 letrec x 1 =E 1 [x i := x E] [x:=x i ],..., x = z.C[z] [x i := x z] [x:=x i ],..., x n =E n [x i := x E] [x:=x i ] in E 0 [x i := x E] [x:=x i ] letrec x 1 = E 1 [x i := x i E],..., x i = z.C[z][x i :=x i z],..., x n = E n [x i := x i E] in E 0 [x i := x i E] 

21/06/2015TCS34 Formalisation of Refactorings letrec has been extended to model the Haskell module system ( M ). The move a definition from one module to another refactoring has also been formalised using M.

21/06/2015TCS35 Future Work Adding more refactoring to HaRe. Making use of type information. Coping with modules without source code. More interaction between HaRe and the user. Further development of the formalisation of refactorings. Metric-based refactoring. Support for scripting refactorings. Porting HaRe to GHC...

21/06/2015TCS36 Questions?