🚀 go-pugleaf

In article <BJORNL.92Oct26175238@asia.sics.se> bjornl@sics.se (Bj|rn Lisper) writes:

   It follows that any "functional" interpreter of practical use must have
   imperative features, since program development involves a test-edit-cycle
   where attempted function definitions are redefined.

In article <TMB.92Oct27115652@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M.
Breuel) writes:

   What I would prefer is an approach to interactive programming that is
   more "declarative". By this I mean that I state to the interpreter
   that a certain piece of text should describe its state. When I modify
   the text, the state of the interpreter should change accordingly and
   automatically. 

My PhD thesis explored a programming environment based on this more "declarative"
concept. The environment, called AIMLESS, provided an interactive test-edit-cycle
system for ML where the current "program" always described the current state of
the system.

In ML it is not possible to re-define a top-level definition. For example
 
   fun f x = x + 1;
   fun g x = (f x) * 2;

If I enter a new definition of f at the top-level, the definition of g uses the
definition of f that existed when g was defined (static top-level binding). In
AIMLESS, to edit the definition of f and to change g, one would "undo" the
the interactive phrase that defined g (fun g x = (f x) * 2;), "undo" the next
phrase that defined f, either change this phrase or enter a new phrase defining f,
"redo" g's definition and the system now has a new definition of f and g now
uses the new definition of f. For convenience, the system provided a
single command that performed these operations.

The "program" in such an interactive sesssion can be thought of as a series of
phrases P1, P2, ... Pn. The concept of "undoing" a phrase can be shown using
a "||" marker, where the phrases to the left are part of the program and define
the state of the system, the phrases to the right have been entered into the
interactive session but are not currently part of the state of the system.
For example, the original program would originally be

   "fun f x = x + 1;" , "fun g x = (f x) * 2;" || 

After one "undo" the system would be represented as

   "fun f x = x + 1;" || "fun g x = (f x) * 2;"

where only "fun f x = x + 1;" is part of the state of the system - i.e. g would
not be bound.

The "undo" operation in AIMLESS was implemented so that it undid all the
internal effects of the phrase - fixity changes, bindings to the environment,
side-effects in memory. The phrases to the left of the "||" therefore were
a consistent record of the state of the system. As ML is a mostly functional
language, the number of side-effects to be undone should be minimal.

AIMLESS also retained the values of expressions entered as tests. For example,
if I defined factorial and entered "factorial 6;", AIMLESS would remember
the result. Any test expressions that were "undone" and then "redone" would
have their previous and current values compared to detect changes that
invalidated previous testing.

Note that in a statically typed language like ML, changing a previous definition
may make later phrases invalid. For example, changing f in the above example
so it returned a boolean rather than an integer would make g have a type
error. Such errors were handled simply in AIMLESS, a phrase entered or "redone"
that was invalid would be placed on the right of "||" and could be either
corrected or re-entered when appropriate.

AIMLESS was implemented as part of an early ML compiler. It was used in some
programming and teaching situations, the environment was easy to learn and use.
Its weaknesses? An environment like AIMLESS is fine for programming in the small (this was what it was designed for). It is not clear what mechanisms are needed
for programming in the large. Tests are valuable across interactive sessions, not
just within one session; AIMLESS did not really address this issue. Finally the
phrases in a session were treated in a linear fashion. More realistically they
would be a partially ordered set.

Other people have looked at the question of top-level bindings and programs;
for example Nikhil has developed a different approach in ID.

John