Hi Mike:

Thank you for your answer explaining the differences.
. I checked with Paul and he provided the 
update below.

-- Karl

From pberg@valhalla.cs.wright.edu Mon Nov 17 12:32:32 1997
Date: Mon, 17 Nov 1997 12:32:50 -0500 (EST)
From: Paul Bergstein <pberg@valhalla.cs.wright.edu>
MIME-Version: 1.0
Subject: your tool

Karl Lieberherr writes:
 > Hi Paul:
 > 
 > I asked Mike Werner to compare his thesis proposal with your thesis.
 > Do you have a tool which implements extensions of your 
 > thesis ideas? Would like to check for overlap.
 > 
 > -- Karl
 > 

Hi Karl,

We are building a tool that implements a number of extensions to my
thesis ideas. So far, we have a graphical front end written in Java,
and most of the transformations from my thesis implemented in C++. We
haven't yet integrated the transformations with the user interface.

Mike is correct that the thesis considers only a "toy" language,
called CDG, and object structures that are trees. These limitations
were imposed to facilitate correctness proofs and demonstrate a sound
theoretical basis for the approach.

A number of people have correctly noted that the use of grammars is
unnecessary for the implementation, and not a limitation of the
method. Still we keep them, since they are the basis of the theory,
allow us to generate parsers for the user's objects, and should help
us apply the method outside the context of evolution (e.g. code reuse
by mapping functionality to a second, independently designed, class
structure).

So far, we support booleans, conditionals, and loops, in addition to
the features described in the thesis. Our intension is to continue
adding features until we support most of the features of "real"
languages such as C++. We have kept the CDG syntax for ease of
parsing, but there is no barrier except a little time to supporting
C++ or Java syntax for the same features.  We are focusing more on C++
than on Java since we can map our support for multiple-inheritance
directly.

We are currently working on adding a "new" operator and removing the
"tree" restriction. The main problem is with transformations that move
parts up the "part-of" hierarchy. Methods that access the moved parts
can obtain indirect access through the parent object in a tree. If
the object structure is not a tree, it is sometimes, but not always,
possible to find a suitable parent object. In the case where a parent
object can't be found, we rely on some user interaction.

Best regards,
-- Paul