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

2. AFP042 Session 1

3. AFP043 Refactoring Refactoring means changing the design or structure of a program … without changing its behaviour. RefactorModify

4. AFP044 Splitting a function in two

5. AFP045 Splitting a function in two

6. AFP046 Splitting a function in two

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

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

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

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

11. AFP0411 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. AFP0412 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. AFP0413 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. AFP0414 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. AFP0415 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. AFP0416 Generalisation f f 9 + 37 h x = … f 9 + 37 … e = h 37 + 12

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

18. AFP0418 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. AFP0419 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. AFP0420 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. AFP0421 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.

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

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

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

25. AFP0425 Modify and refactor

26. AFP0426 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, …

27. AFP0427 Rename 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. Scope: just change occurrences of this f. Modules: change f (and M.f ) everywhere.

28. AFP0428 Lift / demote 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. 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. AFP0429 Lessons from these examples Ensuring correctness requires knowledge of: Lexical structure of programs Abstract syntax Binding structure Type system Module system

30. AFP0430 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. AFP0431 Visualising the effect Estimating the effect of a refactoring. Work by Chris Ryder

32. AFP0432 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.

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

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

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

36. AFP0436 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. AFP0437 Machine support invaluable Reliable Low cost of do / undo, even for large refactorings. Increased effectiveness … and creativity.

38. AFP0438 Demonstration of HaRe, hosted in vim.

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

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

41. AFP0441 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. AFP0442 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. AFP0443 What? Any project of your own choice, perhaps building on other courses at AFP04. Alternatively, a minesweeper program.

44. AFP0444 Minesweeper

45. AFP0445 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. AFP0446 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. AFP0447 Minesweeper extensions Add a GUI … … or animation. Allow backtracking?