Refactoring Functional Programs Simon Thompson with Huiqing Li

Refactoring Functional Programs Simon Thompson with Huiqing Li Claus Reinke www. cs. kent. ac. uk/projects/refactor-fp AFP 04

Session 1 AFP 04 2

Refactoring means changing the design or structure of a program … without changing its behaviour. Modify AFP 04 Refactor 3

Splitting a function in two AFP 04 4

Splitting a function in two AFP 04 5

Splitting a function in two AFP 04 6

Splitting a function module Split where f : : [String] -> String f ys = foldr (++) [] [ y++"n" | y <- ys ] AFP 04 7

Splitting a function module Split where f : : [String] -> String f ys = foldr (++) [] [ y++"n" | y <- ys ] AFP 04 8

Splitting a function module Split where f : : [String] -> String f ys = join [y ++ "n" | y <- ys] where join = foldr (++) [] AFP 04 9

Splitting a function module Split where f : : [String] -> String f ys = join [y ++ "n" | y <- ys] where join = foldr (++) [] AFP 04 10

Splitting a function module Split where f : : [String] -> String f ys = join add. NL where join zs = foldr (++) [] zs add. NL = [y ++ "n" | y <- ys] AFP 04 11

Splitting a function module Split where f : : [String] -> String f ys = join add. NL where join zs = foldr (++) [] zs add. NL = [y ++ "n" | y <- ys] AFP 04 12

Splitting a function module Split where f : : [String] -> String f ys = join (add. NL ys) where join zs = foldr (++) [] zs add. NL ys = [y ++ "n" | y <- ys] AFP 04 13

Splitting a function module Split where f : : [String] -> String f ys = join (add. NL ys) where join zs = foldr (++) [] zs add. NL ys = [y ++ "n" | y <- ys] AFP 04 14

Splitting a function module Split where f : : [String] -> String f ys = join (add. NL ys) join zs = foldr (++) [] zs add. NL ys = [y ++ "n" | y <- ys] AFP 04 15

Generalisation f f 9 + 37 h x = … f 9 + 37 … e = h 37 + 12 AFP 04 16

Generalisation f 9 + 37 hyx=…y… e = h (f 9 + 37) 37 + 12 AFP 04 17

Session 1 Potted history of refactoring. Refactoring and design. Example refactorings … what do we learn? Demonstration of the Ha. Re tool for Haskell. A practical exercise. AFP 04 18

A little bit of history … Floyd, 1978 Turing Award Lecture: encourages reflective revision. Griswold: Automated assistance for (LISP) program restructuring. Opdyke: Refactoring OO Frameworks. Fowler et al: Refactoring: Improving the Design of Existing Code. AFP 04 19

Refactoring in OO Smalltalk refactoring browser … relies heavily on reflection. Built into a number of IDEs: Eclipse, … Refactor and test … major way of ensuring correctness of refactorings … … others require heavyweight static analysis. Link with design … AFP 04 20

Design Structure of the program? • Modules, types, interfaces … Artefact? • UML diagrams of various kinds … • … with accompanying constraints. • Model Driven Architecture Design patterns? The problem of consistency: design vs code. AFP 04 21

Designing functional programs No evidence of an appetite for separate modelling languages … No established terminology of patterns … … it’s all in the code. AFP 04 22

Development of functional programs is spiral … … from a working base, extend, refactor and elaborate. Design emerges. AFP 04 23

Soft Ware There’s no single correct design … … different options for different situations. Maintain flexibility as the system evolves. AFP 04 24

Modify and refactor AFP 04 25

Refactoring functional programs Semantics: can articulate preconditions and verify transformations. Absence of side effects makes big changes predictable and verifiable … unlike OO. Language support: expressive type system; abstraction mechanisms: higher order functions, classes, … AFP 04 26

Rename fxy=… find. Max. Volume x y = … Name may be too specific, if the function is a candidate for reuse. Make the specific purpose of the function clearer. Scope: just change occurrences of this f. Modules: change f (and M. f) everywhere. AFP 04 27

Lift / demote fxy=…h… where h=… f x y = … (h y) … hy=… Hide a function which is Makes h accessible to the clearly subsidiary to f; other functions in the clear up the module and beyond. namespace. Free variables: which parameters of f are used in h? Need h not to be defined at the top level, … , Type of h will generally change … DMR. AFP 04 28

Lessons from these examples Ensuring correctness requires knowledge of: n n n Lexical structure of programs Abstract syntax Binding structure Type system Module system AFP 04 29

Lessons from these examples Changes are not limited to a single point or even a single module: diffuse and bureaucratic … Most refactorings bidirectional … … unlike traditional program transformation. AFP 04 30

Visualising the effect Estimating the effect of a refactoring. Work by Chris Ryder AFP 04 31

Program transformations Operational semantics reduction to normal form Program optimisation source-to-source transformations to get more efficient code Program derivation calculating efficient code from obviously correct specifications Refactoring transforming code structure Related themes, with substantial overlap, and common theory, but with different intentions. AFP 04 32

Conditions: renaming f to g “No change to the binding structure” 1. 2. 3. No two definitions of g at the same level. No capture of g. No capture by g. AFP 04 33

Capture of renamed identifier hx=…h…f…g… where gy=… hx=…h…g…g… where gy=… fx=… gx=… AFP 04 34

Capture by renamed identifier hx=…h…f…g… where fy=…f…g… hx=…h…g…g… where gy=…g…g… gx=… AFP 04 35

Refactoring by hand? By hand = in a text editor Tedious Error-prone • Implementing the transformation … • … and the conditions. Depends on compiler for type checking, … … plus extensive testing. AFP 04 36

Machine support invaluable Reliable Low cost of do / undo, even for large refactorings. Increased effectiveness … and creativity. AFP 04 37

Demonstration of Ha. Re, hosted in vim. AFP 04 38

The refactorings in Ha. Re Move def between modules Rename Delete/add to exports Delete Clean imports Lift / Demote Make imports explicit Introduce definition Remove definition data type to ADT Unfold Short-cut, warm fusion Generalise All module aware Add/remove parameters AFP 04 39

Practical exercise A practical exercise in reflective programming and design. Work together in groups, preferably pairs. AFP 04 40

Two roles The writer writes design or types the program. The logger keeps a log of the process: • Rationale for design decisions. • Refactorings in the design or the coding • Purpose, effect, extent. Regularly swap roles. Better understand refactoring in practice. AFP 04 41

Context ASCII log files plus program(s) … conclusions to go on the web. Mail to sjt@kent. ac. uk To reach a consensus on which refactorings are most useful and commonly used. • Document. • Implement. • Evaluate API. AFP 04 42

What? Any project of your own choice, perhaps building on other courses at AFP 04. Alternatively, a minesweeper program. AFP 04 43

Minesweeper AFP 04 44

Minesweeper Mines distributed in a grid: find and mark all the mines. On revealing a square, lose if it’s occupied, if not see # adjacent. If # is zero, clear connected region. Can also unmark. AFP 04 45

Minesweeper extensions Add deduction: play all the guaranteed moves … … or probability: reveal the square which is least likely to explode. Show the deductions: how large support set for each deduction? AFP 04 46

Minesweeper extensions Add a GUI … … or animation. Allow backtracking? AFP 04 47