Metaprogramming & language design

[Kenneth Dickey]

<somebody> wrote:

> > Suppose you want to find all calls to some routine.  An integrated
> > development environment like Smalltalk allows you to do this search via
> > metaprogramming.  I agree that this is a good thing.  On the other hand, the
> > compiler in Smalltalk can be modified (each class can use a different
> > Compiler class to compile the class's methods).  That is probably a bad
> > thing, because it means the code that searches through the library for all
> > calls to some routine might not work any more.  Or maybe the browsers stop
> > working, or exception handling breaks because of assumptions about the
> > compiler, etc.  If you define a clean, generic protocol for the Compiler
> > class you can avoid some of these problems, but this is just language
> > design!
> >
> > I'm in favor of lots and lots of metaprogramming.  I'm *not* in favor of
> > leaving the system so open to fundamental changes that you can no longer
> > trust a single line of code to do what you expect it to.  Some kinds of
> > metaprogramming are this severe.
>

Two quick observations.

[1] Developing development systems can be done by holding the 'outer' development
environment tobe safely sealed off while building the 'inner'/new environment.  E.g.
see Matthew Flatt, et. al. "Programming Languages as Operating Systems (or Revenge of
the Son of the Liusp Machine)", CIFP '99/SIGPLAN Notices 34(9), September 1999.  In
the PLT/MzScheme environment it is possible to contain 'event spaces', 'io spaces' and
'custodians' (per-process resource control).  [Note that in this case the compiler and
object model were invariant, but a good approach].  I.e. events, resources, and i/o
ports can be safely cleaned up after some disaster in the inner/test context (e.g. a
new IDE) without affecting the outer/stable IDE.

[2] Dave Simmons of QKS introduced scoped symbols into SmalltalkAgents.  I.e. when
dispatching occurs one dispatches on the selector, the object/arguments, AND the
symbol-space/scope of the selector.  Dave says (private communication) that this
allows him to run multiple versions of classes/methods concurrently within a single
Smalltalk workspace.  [Each 'override set' has its own scoped version/symbol space].
This allows, e.g. multiple version of a method to be used without 'confusing' the
objects using them ('older' objects use the older version, newer objects the newer).

The crux in both cases is to be crisp on what is to be held invariant and have a
mechanism to 'seal off' some design/runtime aspect to preserve a 'sanity invariant'.

$0.02,
-KenD