Erlang Extreme Programming & Refactoring, Was: non-telecom in erlang

Luke Gorrie <>
Wed Feb 5 19:23:07 CET 2003

"Eric Newhuis" <> writes:

> This is music to my ears.  I don't know how many Erlang XPers there are out
> there but this might just be tip the scale so that VIM programmer in the
> corner finally learns emacs.
> (Thomas, I am only joking.  Please laugh with me.)
> Refactoring support in Emacs sounds like an amazing accomplishment to help
> optimize XP.  I can't wait to try it out.  Are there a list of refactorings
> somewhere?  I geuss I should read the documentation, i.e. source code.  ;-)

Right now there is one refactoring supported: taking an expression in
a function and moving it into a new separate function. The usage is
described in the message cited in the last mail.

Here's how it really works:

You select an expression as the region in Emacs, and call the
refactor-as-subfunction command (C-c C-d f). It asks for the name of
the new function, and you give it one.

Emacs grabs the text of the expression and sends it over to an Erlang
node. The node uses Richard Carlsson's 'syntax_tools' package to find
out which variables occur free in the expression. If the function was
correct to begin with, then these variables were all locally bound in
the original function, and are the ones we need to pass in to the new
function as context.

Emacs receives the free variable list and rewrites the original source
by turning the to-be-refactored expression into a call to a new
function with all the needed arguments, and generates that new
function with an appropriate argument list and the refactored
expression as the body.

The implementation is really trivial, and I find the function pretty
useful in practice. It would be great to add more similar commands,
but I'm not up to speed on refactoring editors, so I don't really know
what other commands would be good.

We won't easily be able to do such fancy things as editors that
maintain parses of entire source trees at once, like IDEA for Java,
but hopefully there's more low-hanging fruit that we can pick.

The caveat is that if the refactored expression created new variable
bindings, then they won't be exported back into the original
function. But generally this is not the case in normal erlang
programming style.

For reference, the URL to the distel-hackers list message again is:

The copy of Distel in CVS currently works better than the last release
(some debugger breakpoint bugfixes), so if you want to try it you
needn't expect trouble.


More information about the erlang-questions mailing list