🚀 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.

That's a view of program development that comes from the Lisp
tradition. I have always found it rather inconvenient (even with
semi-automatic support like COMPILE-CHANGED-DEFINITIONS-OF-BUFFER),
since it forces the programmer to manually maintain consistency
between his sources and the state of the interpreter, and since you
can never be certain whether some problem is due to a bug in your
sources or an inconsistency between your sources and your interpreter.

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.

The implementation of such a system might very well include some
imperative constructs ("System.Unsafe.redefine_top_level_function"),
but those constructs needn't (and shouldn't) be user-visible.

					Thomas.

PS: Note, incidentally, that NJ/SML does not have "imperative top
level features", in the sense that it is not possible to redefine top
level bindings (you can only shadow them). That forces you to perform
some extra recompilation, but, in the absence of any smart mechanisms,
I find it to be preferable for ensuring better consistency between
sources and interpreter state than what your run-of-the-mill
CommonLisp system gives you.