Philosophical musings: interpreting models

[Jim Little]

This is part two.  It may be read independently of part one.  Here's the
intro again, in case you missed part one:

This email is an unpolished continuation of the thoughts I published in
"The Will and the Word: A Philosophy of Programming"
(http://www.teleport.com/~sphere/documents/0006/4/index.html).  The
fundamental concepts are:

. Programs are abstract concepts.  They are a wish that the world behave
in a certain way.
. Programs are reified as models.  A given program may be expressed by
several different models.
. Machines interpret models.  In so doing, they behave in the way the
program specifies.
. Metamodels are used to understand which program a model describes. 
Metamodels describe a set of models and the corresponding programs.
. Metamodels typically describe models which are related in some way,
and machines typically interpret all of the models in a particular
metamodel.


(Continuing...)
This brings up a point I've had issues with before.  For a model to be
interpreted properly (by "interpreted," in this case, I mean "understood
by an observer"), its CONTEXT must be known.  In other words, the
observer know which metamodel to use to interpret the model.

So, when a model is isomorphically transformed, what happens to the
context?  In order to properly interpret the new model, the observer
must know the model's NEW metamodel.  But to truly understand the
program being modelled, the observer must know the model's ORIGINAL
metamodel!

For example, here's a model which says, "Output a greeting."

   OUTPUT "Hello, World!"

Here's an isomorphic transformation of that model:

   PRINT STDERR, "Hello, World!"

The second model is more specific than the first.  The first merely
specifies that the string be output; the second specifies that it be
output to STDERR.  Strictly speaking, this is not an isomorphic
transformation.

Yet this sort of transformation occurs all the time in computing.  When
a compiler transforms source code to machine code, all sorts of
additional information is added: the order in which certain operations
will occur, the timing involved, etc.

So in order for a model to be fully understood, we need to know TWO
things:

  . The metamodel with which to interpret it
  . The capabilities and limitations of the original model's metamodel.

For example, given this model:
  
  PRINT STDERR, "Hello, World!"

We know that the modeled program prints a greeting to STDERR.  If we
wanted to transform this model further, we wouldn't have much
flexibility.  Any isomorphic transformation would still model a program
which output to STDERR.

On the other hand, if we ALSO knew that the original model's metamodel
didn't have any way to specify the location of the model's output, we
would have a lot more flexibility.  An isomorphic transformation could
create a model whose program output to a text-mode terminal, a
bit-mapped display, or even a file.  That's because we'd still be
modeling the same program: a program which output a greeting.

So it's important to know the limitations of a program's original
metamodel.  And when modeling a new program, it's important to specify
as little as possible (while still specifying everything necessary) so
that metaprograms which operate on the model may have as much
flexibility as possible to optomize the program for the user's current
computing needs.

Jim Little
jiml@inconnect.com