Philosophical musings: interpreters vs. compilers
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!
> 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
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!