Refactoring in Tunes

[Massimo Dentico]

btanksley@hifn.com wrote:
> 
> > From: Laurent Martelli [mailto:martelli@iie.cnam.fr]
> > Subject: Re: Refactoring in Tunes
> 
> > >>>>> "bill" == btanksley  <btanksley@hifn.com> writes:
> 
> >   bill> you're asking for.  "Refactoring" is generally used to
> >   bill> indicate the process of changing the way code put together in
> >   bill> order to produce a better fit to a better design.  In other
> >   bill> Refactoring in this sense cannot be helped by a runtime
> >   bill> system ...

Why not, Bill? You cite meta-programs which does exactly this:

> >   bill> ... and Smalltalk works well because there are automated tools
> >   bill> to performs some of the most common refactorings.

> > think that refactoring does not only apply to OO languages. I see it
> > as finding patterns which are used more than once.
> [snipped: example of finding redundant patterns, making them into a
> function, and calling the function from both places]
> 
> No, that's function factoring, not Refactoring.  My "Refactoring" book calls
> that "Extract Method".  Refactoring also includes the inverse of that --
> "Inline Method".  A good coder should know how to do both refactorings;
> sometimes you need to inline a method in order to get special behavior (or
> because you made a poor choice of factoring earlier and now you have to
> redivide your functions' functionality).

What is the novelty? In the context of lambda-calculus "Extract Method"
is lambda-abstraction and "Inline Method" is beta-reduction, but with
high-order functions and others machineries you can really catch arbitrary
patterns of symbols in a clear manner (IMHO better than in mainstream so-called
"OO languages").

However is known that lambda-unification (are there substitutions which
make equal 2, or N, lambda-terms? Eventually, which are these substitutions?
See the simple example of Laurent Martelli) is semi-decideable(?) (at the best,
you could construct a procedure that terminates if these substitutions exist;
otherwise the procedure won't terminate).
For each reader not familiar with the subject and that doesn't understand:
I'm sorry, but with my limited english, it is difficult to explain these terms.
 
> > When you're dealing with OOL, you introduce new base classes, but it's
> > the same mechanism.
> 
> The full art of refactoring is about being able to change the design of a
> program, not simply make it take up less space.

".. simply make it take up less space" is not futile: this save valuable
resources both for machines and human beings. For example, a program of
100 lines is much more understandable and manegeable than an *equivalent* program
of 10.000 lines (settle 2 programs are equivalent it is not a so simple matter;
for example, see the preceding definition of lambda-unification).

However, the theory of data compression is well developed.

> You accomplish that change in two steps:
> first, you apply source changes which preserve the old behavior
> but provide a more suitable class or function layout (these are
> what Fowler calls "refactorings");
> and second, you change the arrangement of these new classes to provide
> your new behavior.

Well, if I am not wrong, Brian spoke just to **automatize** this process:
discover arbitrary structures (in general sense, not only computable functions),
abstract it from the relative context and riutilize it freely (in automatic or
semi-automatic way).

Good question. Only some suggestions: deduction, induction, neural nets,
genetic programming (with induction, see ADATE to synthetize(?) programs
from input/ouput pairs: http://www-ia.hiof.no/~rolando/adate_intro.html),
and so on. Arrows, Brian?.

P.S.: (?) means: is it correct in english?

-- 
Massimo Dentico