Example of Scenario of Evolutions basd on the Epression Problem

The base program, transformations anv views come from our expression problem example (v0.3). Here are the source code for the initial example and the present example (version 0.3a from the example page).

As in the expression problem example (v0.3), we start with a base program in a function oriented view. That view and the other possible view are pictured below.

1. Extension: Add a new constructor Mult (to represent multiplications).
2. Extension: Add a new function all_positive (to chack that all the constants are positive).
3. Extension: Add a new constructor Div (to represent entire divisions).
4. Extension: Add a new function check (to check that there is no division by zero).
5. Maintenance: Modify the function eval.
6. Maintenance: Modify the data constructor Const.

All ths states and transformation scripts are found in the archive in expr_prob_scenario_0.3b.tgz.

The files of the program in its initial state (function oriented).

The Haskell View Switcher script to transform the initial program in a data oriented view. (Dont' forget to create the HaRe project before running the script, and to add the empty modules AddMod and ConstMod to the project.)

The program after the transformation, data oriented.

The first evolution is implemented: we add a case Mult in the data-type Expr. A module MultMod is created on the model of AddMod (business code). The code for fold, eval and toString are updated to take the new business functions into account (administrative change). Don't forget to add MultMod into the project.

The script to pass from the data oriented view from the function oriented view. Here, that script does not depend on the type Expr (the corresponding business functions and modules are extracted from the program).

The program after the transformation, function oriented.

The second evolution is implemented: we add a function pos to check that all the integers are positive. We add a module PosMod (and add it into the project). The function follow the model of eval for the pattern matching.

The script to pass from the function oriented view from the data oriented view. To take the new function into account, a part of the script has been duplicated by copy/paste and updated with pos and PosMod. Of course, for people mastering LISP, you would prefer to parametrize the script by the name of the function and the corresponding module instead of duplicating code.

The program after the transformation, data oriented.

The third evolution is implemented: we add a constructor Div for division. As for the first evolution, all the business code is in a single module DivMod.

The script transfo_2_data_fun.el is adapted to take the function pos into account. No change is needed to take the contructor Div into account.

The program after the transformation, function oriented.

The fourth evolution is implemented: we add a function check to check divisions by 0. The code is in the module CheckMod can follow the model of any other function. Note that the function check contains a local declaration and that the recursion scheme is not the same as for the other functions.

A maintenance task on a function has been performed: the toString function returns expressions in prefixed form instead of infix. As the program was in function oriented view, the maintenance is modular.

This script is adapted from transfo_3_fun_data.el to take the function check into account. Note that two additional operations are necessary to handle the specificities of check. Also, as the recursion scheme is not the same as for the other functions, fold cannot be reused and a specific iterator will be extracted. Here the script is not uniform with respect to functions anymore but the transformation remains possible.

The program after the transformation, data oriented. The view is convenient for a change in the behavior of a data constructor.