One Day Workshop in Refactoring Functional Programs

last updated: 27/02/2004

Discussion session(s)

We'll probably have less than 12 full presentations, and so should be able to reserve at least one slot (just before lunch, or just before the end) for more formal discussions or practice sessions. Hoping to keep the whole event rather informal, demos can also be integrated with the talks (we'll assume this as the default unless you tell us otherwise), and discussions may emerge at any point.

Among the issues we'd like to raise during the discussion sessions are opportunities for collaboration, and ways in which tool-builders and tool-users could help each other:

• future development of HaRe, and collaborations:
  • which kind of refactorings would you like us to focus our resources on (a list of possible options)?
  • which kind of features would you like to integrate into HaRe's framework (program transformations, IDE features, ..)?
  • what kinds of APIs should we provide for such extensions?
  • might there be opportunities for student projects at your places, to work on aspects of HaRe we don't have resources for at the moment?
• Haskell frontends (GHC, Programatica): what kinds of functionality and APIs would tool-builders like to see
• the general situation of functional program transformations and functionally programmed transformations:
  • Library and frontend support are there now, where are the programmer tools?
  • what can we do to improve the situation?
  • what should be our goals?

Abstracts

Unfolds generate data structures, and folds consume them. A hylomorphism is a fold after an unfold, generating then comsuming a virtual data structure. A metamorphism is the opposite composition, an unfold after a fold; typically, it will convert from one data representation to another.

In general, metamorphisms are less general than hylomorphisms: there is no automatic fusion to deforest the intermediate virtual data structure. However, under certain conditions fusion is possible: some of the work of the unfold can be done before all of the fold is complete. This permits streaming metamorphisms, and among other things allows conversion of infinite data representations.

We present the theory and outline some examples.

An obfuscation is a program transformation whose aim is to make a program "harder to understand" whilst preserving behaviour. Usually obfuscations are used with object-oriented languages but I'll consider obfuscating a functional language. I've adapted an imperative obfuscation - array splitting - to work with Haskell style lists. To demonstrate the techniques, I will look at representing sets and some basic operations using lists. I will show how to derive obfuscations for the set operations by using functional composition. By deriving the obfuscations, one can be sure that the functionality of the operations will not be changed.

In my research I am trying to demonstrate, in the context of imperative (object- and aspect- oriented) programs, how program analysis techniques (such as control-flow, data-flow and slicing) can help in constructing refactoring tools. In particular, we develop support for a slice extraction refactoring designed to enhance reusability of existing entangled code.

Higher-order matching gives us a way of expressing many interesting program transformations as rewrite rules. The MAG system uses it to apply a number of transformations at compile-time, and I'll talk about how these transformations could instead be viewed as refactorings. I'll also discuss one or two other examples of refactorings that higher-order matching might help with.

We compare different approaches to reasoning about functional programs in a case study on the correctness of simple data conversion (printing and parsing). Fixed point induction, the approximation lemma, the improvement theorem and testing are all useful methods but how can we combine them and how can a tool help in constructing correct programs or verifying programs and transformations?
(This work is part of the Cover project at Chalmers.)

I've been working on implementation of partial evaluation in Stratego/XT recently. I could give a 30 min talk about the programming techniques used, accompanied by a short demonstration.

This talk will reflect on operator suites for refactoring and evolution. While functional programming will be one important object language to consider, language parametricity is considered a driving principle. That is, we will also touch upon suites for grammar transformation, suites for rule-based systems such as SOS, and others. We will deal with the following questions:

• What are the ultimate properties of operator suites?
• How much language parametricity can be expected?
• How to turn operator suites into meta-programming frameworks?
• What are the limits of a suite-based approach?
• What are complementary notions (complementing the suites idea)?
• Is there a higher form of XP-like smells, say odours?
• What's the distance between refactoring and evolution?
• What's there besides refactoring and evolution?
• What's the link to transformational programming?

Strafunski is a Haskell-based bundle for generic programming and language processing, based on the notion of a functional strategy. These are generic functions that can traverse into terms of any type while mixing type-specific and uniform behaviour. In this talk we will give an extremely brief overview of Strafunski, touching on the following issues:

• Design decisions and engineering considerations
• Applications of Strafunski (possibly with demo)
• Relation of Strafunski to Haskell's Data.Generics
• Future of Strafunski

Refactorings are meaning-preserving source-to-source program transformations, usually with the goal to implement design-level changes at the level of program source code. HaRe, our prototype refactoring tool for Haskell, implements about a dozen refactorings, and after a first release in October 2003, has just become module-aware (January 2004 release). We will give a brief overview of the current status of HaRe, user-level features, implementation, and possible directions for the future.