[<<][libprim][>>][..]
Sun Jan 10 11:03:59 CET 2010

Reflection and self-hosted compilation

Why is this relevant?

Let's abuse terminology and call what was called "incremental
bootstrap" a special case of reflection: the ability of a language to
change its own semantics in some way.

Note that in our case, we change compile-time semantics (macros) in a
bottom-up, linear fashion.  I.e. code, once compiled, does not change
semantics.  This can then be augmented by either early or late binding
of run-time code (redefining procedures).

Some assumptions:

- Interactive console acces is useful for debugging.

- Some form of compilation (to native or VM code) is necessary for
  efficiency.

From this follows that we need an in-image compiler to compile source
code to executable format.

- Using reflection (i.e. giving up phase separation allowing compiler
  extension to change language semantics on the fly) can lead to very
  small run-time systems.

Two examples that illustrate this: Forth and COLA.  The downside of
powerful reflection is the absence of clear compile-time semantics:
there is essentially only behaviour, no static meaning.  I.e. the only
way to get any information about what a program means is to feed it
into the system and see what it does.

It seems to me that the difficulty associated with incremental
bootstrap (the ``puzzle'' factor) translates directly into smaller
code size, probably as a consequence of the very aggressive factoring
required.


Conclusion:

  Reflection in the form of incremental compiler extensions gives up
  static semantics and gets small code size in return.



[Reply][About]
[<<][libprim][>>][..]