Philosophical musings: interpreters vs. compilers

[Jim Little]

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
(http://www.essaim.univ-mulhouse.fr/uml/documentation/version1.0/glossary/glossary.html)
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!

Jim