[Haskell-cafe] Refactoring status

[Peter Verswyvelen]

>> Furthermore, when I need to perform refactoring, a rename is
>>  just *one* change to the entire system, no matter how many other files
use
>>  the name; no more merging for stupid renames.
> I'm a little confused as to what you mean here. A renaming renames all
> (and only those) uses of an identifier within a particular definition, and
> not every use of a particular name. The binding structure of the program

Suppose we have a file Foo.hs, with the content:

foo ::Int
foo = 42

Translated into a syntax tree, this might look like (majorly simplified)

<Definition id="68684" name="foo">
    <Constant value="42" type="Int"/>
</Definition>

and a file Bar.hs, with

bar :: Int
bar = foo + 27

or translated

<Definition id="577647" name="bar">
    <Add>
	 <Reference id="68684"/>
       <Constant value="27" type="Int"/>
    </Add>
</Definition>

If you rename foo, using textual representation, both Foo.hs and Bar.hs will
be touched / checked-out.

However, if you work directly on the structure, then only the Foo XML file
is changed, Bar is not changed at all.

Of course this might only be the case with renames, more complex
refactorings usually require modifying other files :) 

Anyway, I hate merges caused by renames by others. And many developers tend
to leave names as they are, because you get used to strange names anyway...
A good example is Microsoft's Windows Presentation Foundation code: what do
you think the method FindName on an element tree does? It searches for an
element with a particular name, and returns that element ;)

> There is also (preliminary at the moment) duplicate code detection built
> into HaRe. This is based on the principle of looking at the shape of
functions and
> expressions, concentrating on where variables are bound and whether one
> term is an intance of another. Duplicate expressions can be converted into
> a more general abstraction, transforming the duplicate expressions into
> function calls (parameterised by their differences).

Impressive!

Cheers,
Peter