1 / 28

Refactoring Functional Programs

Refactoring Functional Programs. Huiqing Li Simon Thompson Computing Lab. Chris Brown Claus Reinke University of Kent. Overview. Refactoring tools. Functional programming. Haskell and Erlang. Tools and tool building. Tool design. Experience. Introduction. Refactoring tool support.

damia
Télécharger la présentation

Refactoring Functional Programs

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RefactoringFunctional Programs Huiqing Li Simon Thompson Computing Lab Chris Brown Claus Reinke University of Kent WRT 2007

  2. Overview • Refactoring tools. • Functional programming. • Haskell and Erlang. • Tools and tool building. • Tool design. • Experience. WRT 2007

  3. Introduction WRT 2007

  4. Refactoring tool support • Bureaucratic and diffuse. • Tedious and error prone. • Semantics: scopes, types, modules, … • Undo/redo • Enhanced creativity WRT 2007

  5. Functional Programming λ • Values not variables. • Expressions not :=. • Functions as data. • Rich data and types. • Controlled side-effects. • Declarative descriptions of refactorings. WRT 2007

  6. Strong, static types. Lazy evaluation. Layout sensitive. Concurrency library. Haskell 98 standard. GHC, NHC, Hugs, … Academic, O/S apps. Weak, dynamic types. Strict evaluation. Hot code swap, apply etc. Concurrency built-in. OTP, design patterns. Single system. Industrial applications. Haskell Erlang WRT 2007

  7. -module (test). -export([f/1]). add_one ([H|T]) -> [H+1 | add_one(T)]; add_one ([]) -> []. f(X) -> add_one(X). -module (test). -export([f/1]). add_one (N, [H|T]) -> [H+N | add_one(N,T)]; add_one (N,[]) -> []. f(X) -> add_one(1, X). Generalisation Generalisation and renaming -module (test). -export([f/1]). add_int (N, [H|T]) -> [H+N | add_int(N,T)]; add_int (N,[]) -> []. f(X) -> add_int(1, X). WRT 2007

  8. -export([printList/1]). printList([H|T]) -> io:format("~p\n",[H]), printList(T); printList([]) -> true. printList([1,2,3]) -export([printList/2]). printList(F,[H|T]) -> F(H), printList(F, T); printList(F,[]) -> true. printList( fun(H) -> io:format("~p\n", [H]) end, [1,2,3]). Generalisation WRT 2007

  9. pid! {self(),msg} {Parent,msg} -> body pid! {self(),msg}, receive {pid, ok}-> ok {Parent,msg} -> Parent! {self(),ok}, body Asynchronous to synchronous WRT 2007

  10. The tools WRT 2007

  11. HaRe: the Haskell Refactorer Structural, data type, and module-level. In Haskell: embedded in gvim and emacs. Uses the Programatica framework … … + Strafunski program transformation library. WRT 2007

  12. Wrangler: refactoring Erlang Structural, data type and module-level refactorings. In Erlang plus emacs. Uses the Erlang system framework … … + untyped Erlang transformation library. Respects aspects of the macro system. WRT 2007

  13. Design to be usable WRT 2007

  14. Coverage and Standards • De jure standard, Haskell 98, … • vs de facto standard Glasgow Haskell. • Standard release pattern of Open Source Erlang supervised by the OTP team at Ericsson. WRT 2007

  15. Integration … with IDEs • Back to the future? Programmers' preference for emacs and gvim … • … though some IDE interest: Visual Studio, Eclipse, NetBeans. • Issue of integration with multiple IDEs: HaRe interfaces with emacs and gvim. WRT 2007

  16. Integration … with tools • Test data sets and test generation. • Makefiles, etc. • Working with macros e.g. QuickCheck uses Erlang macros … • … in a particular idiom. WRT 2007

  17. -- This is an example • module Main where • sumSquares x y = sq powx + sq powy • where pow = 2 :: Int • sq :: Int->Int->Int • sq pow x = x ^ pow • main = sumSquares 10 20 • module Main where • sumSquares x y • = sq powx + sq powy where pow = 2 :: Int • sq :: Int->Int->Int • sq pow x = x ^ pow • main = sumSquares 10 20 Preserving appearance • -- 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 WRT 2007

  18. Experience WRT 2007

  19. Transformation Ensure change at all those points needed. Ensure change at only those points needed. Condition Is the refactoring applicable? Will it preserve the semantics of the module? the program? Refactoring = Transformation + Condition WRT 2007

  20. Condition > Transformation • Renaming an identifier • "The existing binding structure should not be affected. No binding for the new name may intervene between the binding of the old name and any of its uses, since the renamed identifier would be captured by the renaming. Conversely, the binding to be renamed must not intervene between bindings and uses of the new name." WRT 2007

  21. Which refactoring exactly? • Generalise f by making 23 a parameter of f: • f x = 23 + g x • where g x = x + 23 + con • con = 23 • This one occurrence? • All occurrences (in the body)? • Some of the occurrences … to be selected. WRT 2007

  22. Compensate or fail? • Lift g to a global definition in • f x = x + g x • where g x = x + con • con = 37 • Fail because con not defined globally? • Add extra parameter to g, and pass in con? • Liftcon as well? WRT 2007

  23. -export([oldFun/1, newFun/1]). oldFun(L) -> newFun(L). newFun(L) -> … … . -export([newFun/1]). newFun(L) -> … … . Compensate or crash? or ? WRT 2007

  24. Infrastructure • Requirement for heavyweight infrastructure. • Best not to write your own! • Compiler APIs. • Often non-existent. • Can change with releases. • Clearly system specific. • Tracking changes in systems and libraries. WRT 2007

  25. APIs … programmer / user • API in Haskell / Erlang to support user-programmed refactorings: • declarative, straightforward and complete • but relatively low-level. • Higher-level combining forms? • OK for transformations, but need a separate condition language? WRT 2007

  26. Verification and validation • Possible to write formal proofs of correctness: • check conditions and transformations • different levels of abstraction • possibly-name binding substitution for renaming etc. • more abstract formulation for e.g. data type changes. • Use of QuickCheck to verify refactorings in both Haskell and Erlang. WRT 2007

  27. Future work • Concurrency. • Refactoring within a design library: OTP. • Side-effects. • Working with Erlang Training and Consulting. • Data-type refactorings in Haskell. • Integration with other IDEs / compilers. • Test and property refactoring. WRT 2007

  28. Conclusion WRT 2007

More Related