1. Huiqing Li Claus Reinke Simon Thompson Computing Lab, University of Kent www.cs.kent.ac.uk/projects/refactor-fp/ Refactoring Functional Programs

2. Manchester 042 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> String format [] = [] format [x] = [x] format (x:xs) = (x ++ "\t") : fomrat xs

3. Manchester 043 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> String format [] = [] format [x] = [x] format (x:xs) = (x ++ "\t") : fomrat xs

4. Manchester 044 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> String format [] = [] format [x] = [x] format (x:xs) = (x ++ "\t") : format xs

5. Manchester 045 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> String format [] = [] format [x] = [x] format (x:xs) = (x ++ "\t") : format xs

6. Manchester 046 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> [String] format [] = [] format [x] = [x] format (x:xs) = (x ++ "\t") : format xs

7. Manchester 047 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> [String] format [] = [] format [x] = [x] format (x:xs) = (x ++ “\t") : format xs

8. Manchester 048 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format format :: [String] -> [String] format [] = [] format [x] = [x] format (x:xs) = (x ++ "\n") : format xs

9. Manchester 049 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format appNL :: [String] -> [String] appNL [] = [] appNL [x] = [x] appNL (x:xs) = (x ++ "\n") : appNL xs

10. Manchester 0410 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. format appNL :: [String] -> [String] appNL [] = [] appNL [x] = [x] appNL (x:xs) = (x ++ "\n") : appNL xs

11. Manchester 0411 Writing a program -- appNL a list of Strings, one per line table :: [String] -> String table = concat. appNL appNL :: [String] -> [String] appNL [] = [] appNL [x] = [x] appNL (x:xs) = (x ++ "\n") : appNL xs

12. Manchester 0412 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. appNL appNL :: [String] -> [String] appNL [] = [] appNL [x] = [x] appNL (x:xs) = (x ++ "\n") : appNL xs

13. Manchester 0413 Writing a program -- format a list of Strings, one per line table :: [String] -> String table = concat. appNL where appNL :: [String] -> [String] appNL [] = [] appNL [x] = [x] appNL (x:xs) = (x ++ "\n") : appNL xs

14. Manchester 0414 Refactoring Refactoring means changing the design of program … … without changing its behaviour. Refactoring comes in many forms micro refactoring as a part of program development, major refactoring as a preliminary to revision, as a part of debugging, … As programmers, we do it all the time.

15. Manchester 0415 Not just programming Paper or presentation moving sections about; amalgamate sections; move inline code to a figure; animation; … Proof introduce lemma; remove, amalgamate hypotheses, … Program the topic of the lecture

16. Manchester 0416 Overview of the talk Example refactorings … what do we learn? Refactoring functional programs Generalities Tooling: demo, rationale, design. What comes next? Conclusions

17. Manchester 0417 Refactoring Functional Programs 3-year EPSRC-funded project  Explore the prospects of refactoring functional programs  Catalogue useful refactorings  Look into the difference between OO and FP refactoring  A real life refactoring tool for Haskell programming  A formal way to specify refactorings … and a set of proofs that the implemented refactorings are correct. Currently mid-project: the latest HaRe release is module-aware and has module refactorings.

18. Manchester 0418 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, HOFs, … Opens up other possibilities … proof …

19. Manchester 0419 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. Needs scope information: just change this f and not all f s (e.g. local definitions or variables). Needs module information: change f wherever it is imported.

20. Manchester 0420 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. Needs free variable information: which of the parameters of f is used in the definition of h ? Need h not to be defined at the top level, …, DMR.

21. Manchester 0421 Lessons from the first examples Changes are not limited to a single point or even a single module: diffuse and bureaucratic … … unlike traditional program transformation. Many refactorings bidirectional … … as there is never a unique correct design.

22. Manchester 0422 How to apply refactoring? By hand, in a text editor Tedious Error-prone Depends on extensive testing With machine support Reliable Low cost: easy to make and un-make large changes. Exploratory … a full part of the programmer’s toolkit.

23. Manchester 0423 Machine support invaluable Current practice: editor + type checker (+ tests). Our project: automated support for a repertoire of refactorings … … integrated into the existing development process: Haskell IDEs such as vim and emacs.

24. Manchester 0424 Demonstration of HaRe, hosted in vim.

25. Manchester 0425 Proof of concept … To show proof of concept it is enough to: build a stand-alone tool, work with a subset of the language, ‘pretty print’ the refactored source code in a standard format.

26. Manchester 0426 … or a useful tool? To make a tool that will be used we must: integrate with existing program development tools: the program editors emacs and vim: only add to their capabilities; work with the complete Haskell 98 language; preserve the formatting and comments in the refactored source code; allow users to extend and script the system.

27. Manchester 0427 Refactorings implemented in HaRe Rename Delete Lift (top / one level) Demote Introduce definition Remove definition Unfold Generalise Add / remove params All these refactorings are module aware. Move def between modules Delete /add to exports Clean imports Make imports explicit

28. Manchester 0428 The Implementation of Hare Information gathering Pre-condition checking Program transformation Program rendering

29. Manchester 0429 Information needed Syntax: replace the function called sq, not the variable sq …… parse tree. Static semantics: replace this function sq, not all the sq functions …… scope information. Module information: what is the traffic between this module and its clients …… call graph. Type information: replace this identifier when it is used at this type …… type annotations.

30. Manchester 0430 Infrastructure To achieve this we chose to: build a tool that can interoperate with emacs, vim, … yet act separately. leverage existing libraries for processing Haskell 98, for tree transformation, yet … … modify them as little as possible. be as portable as possible, in the Haskell space.

31. Manchester 0431 The Haskell background Libraries parser:many type checker:few tree transformations:few Difficulties Haskell98 vs. Haskell extensions. Libraries: proof of concept vs. distributable. Source code regeneration. Real project

32. Manchester 0432 Programatica Project at OGI to build a Haskell system … … with integral support for verification at various levels: assertion, testing, proof etc. The Programatica project has built a Haskell front end in Haskell, supporting syntax, static, type and module analysis … … freely available under BSD licence.

33. Manchester 0433 The Implementation of Hare Information gathering Pre-condition checking Program transformation Program rendering

34. Manchester 0434 First steps … lifting and friends Use the Haddock parser … full Haskell given in 500 lines of data type definitions. Work by hand over the Haskell syntax: 27 cases for expressions … Code for finding free variables, for instance …

35. Manchester 0435 Finding free variables … 100 lines instance FreeVbls HsExp where freeVbls (HsVar v) = [v] freeVbls (HsApp f e) = freeVbls f ++ freeVbls e freeVbls (HsLambda ps e) = freeVbls e \\ concatMap paramNames ps freeVbls (HsCase exp cases) = freeVbls exp ++ concatMap freeVbls cases freeVbls (HsTuple _ es) = concatMap freeVbls es … etc.

36. Manchester 0436 This approach Boiler plate code … … 1000 lines for 100 lines of significant code. Error prone: significant code lost in the noise. Want to generate the boiler plate and the tree traversals … … DriFT: Winstanley, Wallace … Strafunski: Lämmel and Visser

37. Manchester 0437 Strafunski Strafunski allows a user to write general (read generic), type safe, tree traversing programs … … with ad hoc behaviour at particular points. Traverse through the tree accumulating free variables from component parts, except in the case of lambda abstraction, local scopes, … Strafunski allows us to work within Haskell … other options are under development.

38. Manchester 0438 Rename an identifier rename:: (Term t)=>PName->HsName->t->Maybe t rename oldName newName = applyTP worker where worker = full_tdTP (idTP ‘adhocTP‘ idSite) idSite :: PName -> Maybe PName idSite v@(PN name orig) | v == oldName = return (PN newName orig) idSite pn = return pn

39. Manchester 0439 The coding effort Transformations with Strafunski are straightforward … … the chore is implementing conditions that guarantee that the transformation is meaning- preserving. This is where much of our code lies.

40. Manchester 0440 The Implementation of Hare Information gathering Pre-condition checking Program transformation Program rendering

41. Manchester 0441 Program rendering example -- This is an example module Main where sumSquares x y = sq x + sq y where sq :: Int->Int sq x = x ^ pow pow = 2 :: Int main = sumSquares 10 20 Promote the definition of sq to top level

42. Manchester 0442 Program rendering example module Main where sumSquares x y = sq pow x + sq pow y where pow = 2 :: Int sq :: Int->Int->Int sq pow x = x ^ pow main = sumSquares 10 20 Using a pretty printer: comments lost and layout quite different.

43. Manchester 0443 Program rendering example -- This is an example module Main where sumSquares x y = sq x + sq y where sq :: Int->Int sq x = x ^ pow pow = 2 :: Int main = sumSquares 10 20 Promote the definition of sq to top level

44. Manchester 0444 Program rendering example -- This is an example module Main where sumSquares x y = sq pow x + sq pow y where pow = 2 :: Int sq :: Int->Int->Int sq pow x = x ^ pow main = sumSquares 10 20 Layout and comments preserved.

45. Manchester 0445 Rendering: our approach White space and comments in the token stream. 2 views of the program: token stream and AST. Modification of the AST guides the modification of the token stream. After a refactoring, the program source is extracted from the token stream not the AST. Use heuristics to associate comments with semantic entities.

46. Manchester 0446 Production tool (version 0) Programatica parser and type checker Refactor using a Strafunski engine Render code from the token stream and syntax tree.

47. Manchester 0447 Production tool (version 1) Programatica parser and type checker Refactor using a Strafunski engine Render code from the token stream and syntax tree. Pass lexical information to update the syntax tree and so avoid reparsing

48. Manchester 0448 Module awareness: example Move a top-level definition f from module A to B. -- Is f defined at the top-level of B? -- Are the free variables in f accessible within module B? -- Will the move require recursive modules? -- Remove the definition of f from module A. -- Add the definition to module B. -- Modify the import/export lists in module A, B and the client modules of A and B if necessary. -- Change uses of A.f to B.f or f in all affected modules. -- Resolve ambiguity.

49. Manchester 0449 What have we learned? Emerging Haskell libraries make it a practical platform. Efficiency issues … type checking large systems. Limitations of IDE interactions in vim and emacs. Reflections on Haskell itself.

50. Manchester 0450 Reflecting on Haskell Cannot hide items in an export list (though you can on import). The formal semantics of pattern matching is problematic. ‘Ambiguity’ vs. name clash. ‘Tab’ is a nightmare! Correspondence principle fails …

51. Manchester 0451 Correspondence Operations on definitions and operations on expressions can be placed in correspondence (R.D.Tennent, 1980)

52. Manchester 0452 Correspondence Definitions where f x y = e f x | g1 = e1 | g2 = e2 Expressions let \x y -> e f x = if g1 then e1 else if g2 …

53. Manchester 0453 Where do we go next? Larger-scale examples: ADTs, monads, … An API for do-it-yourself refactorings, or … … a language for composing refactorings Detecting ‘bad smells’ Evolving the evidence: GC6.

54. Manchester 0454 What do users want? Find and remove duplicate code. Argument permutations. Data refactorings. More traditional program transformations. Monadification.

55. Manchester 0455 Monadification (cf Erwig) r = f e1 e2 dov1 <- e1 v2 <- e2 r <- f v1 v2 return r

56. Manchester 0456 Larger-scale examples More complex examples in the functional domain; often link with data types. Dawning realisation that can some refactorings are pretty powerful. Bidirectional … no right answer.

57. Manchester 0457 Algebraic or abstract type? data Tr a = Leaf a | Node a (Tr a) (Tr a) Tr Leaf Node flatten :: Tr a -> [a] flatten (Leaf x) = [x] flatten (Node s t) = flatten s ++ flatten t

58. Manchester 0458 Algebraic or abstract type? data Tr a = Leaf a | Node a (Tr a) (Tr a) isLeaf = … isNode = … … Tr isLeaf isNode leaf left right mkLeaf mkNode flatten :: Tr a -> [a] flatten t | isleaf t = [leaf t] | isNode t = flatten (left t) ++ flatten (right t)

59. Manchester 0459 Algebraic or abstract type?  Pattern matching syntax is more direct … … but can achieve a considerable amount with field names. Other reasons? Simplicity (due to other refactoring steps?).  Allows changes in the implementation type without affecting the client: e.g. might memoise Problematic with a primitive type as carrier. Allows an invariant to be preserved.

60. Manchester 0460 Outside or inside? data Tr a = Leaf a | Node a (Tr a) (Tr a) isLeaf = … … Tr isLeaf isNode leaf left right mkLeaf mkNode flatten :: Tr a -> [a] flatten t | isleaf t = [leaf t] | isNode t = flatten (left t) ++ flatten (right t)

61. Manchester 0461 Outside or inside? data Tr a = Leaf a | Node a (Tr a) (Tr a) isLeaf = … … flatten = … Tr isLeaf isNode leaf left right mkLeaf mkNode flatten

62. Manchester 0462 Outside or inside?  If inside and the type is reimplemented, need to reimplement everything in the signature, including flatten. The more outside the better, therefore.  If inside can modify the implementation to memoise values of flatten, or to give a better implementation using the concrete type. Layered types possible: put the utilities in a privileged zone.

63. Manchester 0463 API Refactorings Refactoring utilities Strafunski Haskell

64. Manchester 0464 DSL Refactorings Refactoring utilities Strafunski Haskell Combining forms

65. Manchester 0465 Detecting ‘bad smells’ Work by Chris Ryder

66. Manchester 0466 Evolving the evidence Dependable System Evolution is the software engineering grand challenge. Build systems with evidence of their dependability … … but this begs the question of how to evolve the evidence in line with the system. Refactoring proofs, test coverage data etc.

67. Manchester 0467 Teaching and learning design Exciting prospect of using a refactoring tool as an integral part of an elementary programming course. Learning a language: learn how you could modify the programs that you have written … … appreciate the design space, and … the features of the language.

68. Manchester 0468 Conclusions Refactoring + functional programming: good fit. Practical tool … not ‘yet another type tweak’. Leverage from available libraries … with work. We have begun to use the tool in building itself! Much more to do than we have time for. Martin Fowler’s ‘Rubicon’: ‘extract definition’ … in HaRe version 1 … fp productivity.

69. www.cs.kent.ac.uk/projects/refactor-fp/