refactoring functional programs
Download
Skip this Video
Download Presentation
Refactoring Functional Programs

Loading in 2 Seconds...

play fullscreen
1 / 47

Refactoring Functional Programs - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

Refactoring Functional Programs. Simon Thompson with Huiqing Li Claus Reinke www.cs.kent.ac.uk/projects/refactor-fp. Session 1 . Refactoring. Refactoring means changing the design or structure of a program … without changing its behaviour. Modify. Refactor.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Refactoring Functional Programs' - maile-dixon


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
refactoring functional programs

Refactoring Functional Programs

Simon Thompson

with

Huiqing Li

Claus Reinke

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

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

Modify

Refactor

splitting a function
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = foldr (++) [] [ y++"\n" | y <- ys ]
splitting a function1
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = foldr (++) [] [ y++"\n" | y <- ys ]
splitting a function2
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = join [y ++ "\n" | y <- ys]
  • where
  • join = foldr (++) []
splitting a function3
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = join [y ++ "\n" | y <- ys]
  • where
  • join = foldr (++) []
splitting a function4
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = join addNL
  • where
  • join zs = foldr (++) [] zs
  • addNL = [y ++ "\n" | y <- ys]
splitting a function5
Splitting a function
  • module Split where
  • f :: [String] -> [String] -> String
  • f ys = join addNL
  • where
  • join zs = foldr (++) [] zs
  • addNL = [y ++ "\n" | y <- ys]
splitting a function6
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]
splitting a function7
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]
splitting a function8
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]
generalisation
Generalisation

f 9 + 37

f

h x = … f 9 + 37 …

e = h 37 + 12

generalisation1
Generalisation

f 9 + 37

h y x = … y …

e = h (f 9 + 37) 37 + 12

session 11
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.
a little bit of history
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.
refactoring in oo
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 …
design
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.
designing functional programs
Designing functional programs
  • No evidence of an appetite for separate modelling languages …
  • No established terminology of patterns …
  • … it’s all in the code.
development
Development
  • Development of functional programs is spiral …
  • … from a working base, extend, refactor and elaborate.
  • Design emerges.
soft ware
Soft Ware
  • There’s no single correct design …
  • … different options for different situations.
  • Maintain flexibility as the system evolves.
refactoring functional programs1
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, …
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.

Rename

Scope: just change occurrences of thisf.

Modules: change f(and M.f)everywhere.

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.

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.

lessons from these examples
Lessons from these examples
  • Ensuring correctness requires knowledge of:
  • Lexical structure of programs
  • Abstract syntax
  • Binding structure
  • Type system
  • Module system
lessons from these examples1
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.
visualising the effect
Visualising the effect

Estimating the effect of a refactoring.

Work by

Chris Ryder

program transformations
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.
conditions renaming f to g
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.
capture of renamed identifier
h x = … h … f … g …

where

g y = …

f x = …

h x = … h … g … g …

where

g y = …

g x = …

Capture of renamed identifier
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 = …

Capture by renamed identifier
refactoring by hand
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.
machine support invaluable
Machine support invaluable
  • Reliable
  • Low cost of do / undo, even for large refactorings.
  • Increased effectiveness … and creativity.
the refactorings in hare
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
practical exercise
Practical exercise
  • A practical exercise in reflective programming and design.
  • Work together in groups, preferably pairs.
two roles
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.
context
Context
  • ASCII log files plus program(s) … conclusions to go on the web.
  • Mail to [email protected]
  • To reach a consensus on which refactorings are most useful and commonly used.
      • Document.
      • Implement.
      • Evaluate API.
slide43
What?
  • Any project of your own choice, perhaps building on other courses at AFP04.
  • Alternatively, a minesweeper program.
minesweeper1
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.
minesweeper extensions
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?
minesweeper extensions1
Minesweeper extensions
  • Add a GUI …
  • … or animation.
  • Allow backtracking?
ad