Refactoring Functional Programs

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

2. Session 1

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

4. Splitting a function in two

5. Splitting a function in two

6. Splitting a function in two

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

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

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

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

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

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

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

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

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

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

17. Generalisation f 9 + 37 h y x = … y … e = h (f 9 + 37) 37 + 12

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

19. 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.

20. 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 …

21. 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 vscode.

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

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

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

25. Modifyand refactor

26. Refactoring functionalprograms • 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, …

27. f x y = …  Name may be too specific, if the function is a candidate for reuse. findMaxVolume x y = …  Make the specific purpose of the function clearer. Rename Scope: just change occurrences of thisf. Modules: change f(and M.f)everywhere.

28. f x y = … h … where h = …  Hide a function which is clearly subsidiary to f; clear up the namespace. f x y = … (h y) … h y = …  Makes h accessible to the other functions in the module and beyond. Lift / demote 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.

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

30. 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.

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

32. Program transformations • Operational semantics reduction to normal form • Program optimisationsource-to-source transformations to get more efficient code • Program derivationcalculating efficient code from obviously correct specifications • Refactoringtransforming code structure • Related themes, with substantial overlap, and common theory, but with different intentions.

33. Conditions: renaming f to g • “No change to the binding structure” • No two definitions of g at the same level. • No capture ofg. • No capture byg.

34. h x = … h … f … g … where g y = … f x = … h x = … h … g … g … where g y = … g x = … Capture of renamed identifier

35. h x = … h … f … g … where f y = … f … g … g x = … h x = … h … g … g … where g y = … g … g … g x = … Capture by renamed identifier

36. 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.

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

38. Demonstration of HaRe, hosted in vim.

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

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

41. 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.

42. 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.

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

44. Minesweeper

45. 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.

46. 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?

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