Philosophical musings: interpreters vs. compilers

Jim Little
Sat, 04 Sep 1999 21:50:06 -0600

Paul Dufresne wrote:
> On Sat, Sep 04, 1999 at 03:40:47PM -0600, Jim Little wrote:
> > This email is an unpolished continuation of the thoughts I published in
> > "The Will and the Word: A Philosophy of Programming"
> Welcome back!

Thanks :)

> I have some problems with your vocabulary. And it has ever make it
> difficult to follows your ideas. I think you will not like the fact
> that I can't follow your vocabulary since the time you try to make
> it clear, but since you seems to make it back to square one, let
> me take the occasion to step in and ask clarifications.

No problem.  I'm always trying to make myself more clear.

> > . Programs are abstract concepts.  They are a wish that the world behave
> > in a certain way.
> I call that program specification.

I would say that a program specification is just another model of the
program.  (I assume by "program specification" you mean a written or
verbal description of a program.)

> > . Programs are reified as models.  A given program may be expressed by
> > several different models.
> I think what you call models, I simply call programs.

I've gone with a narrow definition of "program" in order to distinguish
source code from what it represents.

> > . Metamodels are used to understand which program a model describes.
> > Metamodels describe a set of models and the corresponding programs.
> Is a metamodel a programming language?

Not always, but a programming language is always a metamodel.

> My translations seems to fit with the usage you do, but then you
> should not be surprised to have some problems to communicate your
> ideas if you invent new words for concepts that have already well
> known words.

Let me know what those words are, and I'll happily use them. :)  But I
haven't invented any words -- model, metamodel, and even meta-metamodel
are existing terms with well-defined meanings.  I may have generalized
their meaning somewhat, but even so, my usage is consistent with
standard usage.

Look at this UML glossary
and you'll see that my definitions are quite close to theirs.

> Now about compilers and interpreters. The way I see it, compilers
> and interpreters are programs. As such, they have program
> specifications which is for the interpreter, to take a program
> written in programming language X and execute it, and for the
> compiler to take the same input as the interpreter, but generate
> code for a programming language Z that is supposed to be a
> programming language of lower or equal level to the programming
> language Y in which the interpreter or compiler is written.

I disagree with the last part.  There's no reason why Z needs to be at a
lower level than Y.  Perhaps you meant to say X instead of Y?

> So if the interpreter is interpreted, it is using the Y interpreter
> to execute it's input program and if the interpreter is
> compiled, it then use the generated code of Y compiler to execute
> it's input program.
> On the other hand, the compiler don't use the execution power
> given by Y to execute the Z program, but have to translate it to Z,
> and will be executed by a Z compiler or interpreter.
> If Z is assembler, the Z interpreter will be a machine with a
> Z CPU interpreter.

Sounds right to me!