From newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!mcsun!uknet!edcastle!aisb!jeff Fri Jan 31 10:26:49 EST 1992
Article 3246 of comp.ai.philosophy:
Xref: newshub.ccs.yorku.ca comp.ai.philosophy:3246 sci.philosophy.tech:1989
Path: newshub.ccs.yorku.ca!ists!helios.physics.utoronto.ca!news-server.ecf!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!mcsun!uknet!edcastle!aisb!jeff
>From: jeff@aiai.ed.ac.uk (Jeff Dalton)
Newsgroups: comp.ai.philosophy,sci.philosophy.tech
Subject: Re: Implementation (was: Re: Causes and Reasons)
Message-ID: <1992Jan29.005249.10405@aisb.ed.ac.uk>
Date: 29 Jan 92 00:52:49 GMT
References: <6467@pkmab.se> <6026@skye.ed.ac.uk> <6519@pkmab.se>
Sender: news@aisb.ed.ac.uk (Network News Administrator)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 239

In article <6519@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes:
>In article <6026@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>>In article <6467@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes:

>>But the actual implementation of a language doesn't have to be
>>anything like the virtual machine.
>
>If you're meaning to criticize the idea of a virual machine here, then you

I'm not.

>are off the mark. In the general case, the idea of a virtual machine is
>useful whether or not it corresponds directly to the physical machine,
>similar to how a model is useful in connection to a mathematical theory.

I agree that they're useful.

>If you're criticising the connection of the idea of an implementation to
>the virtual machine, then you are obviously refering to some preconceived
>idea of yours of what an implementation may be, that does not match the
>strict sense of implementation that I think David Chalmers has in mind.

My idea of implementation is, so far as I know, entirely in line
with what language standards sometimes call "conforming implementations"
and with what people mean when they say they've implemented some
language or specification.

David Chalmers seems to be thinking of something else, something
where the allowed implementations are severely constrained.

You wrote:

>>>                                              Each execution step
>>>brings the "virtual machine" of that language from one "state" to
>>>the next.

>Note that it is called "virtual" machine because it is NOT the real physical
>machine. It's not a machine at all, just the thought of a machine. In case
>that wasn't clear.

It was entriely clear.

>> For instance, pure Lisp could run on a C machince, or a machine that
>>does reduction (the spineless G machine, perhaps) or a machine that does
>>logical inference.
>
>I'm afraid I don't know the difference between pure and impure Lisp.

Pure means more less applicative or strictly functional.

>Anyway, as long as the language that you are implementing is considered to
>specify an algorithm, i.e. a sequence of actions, and not something else
>like for instance a set of equations to be solved by arbitrary means, or
>a declaration of the desired final result to be achieved by arbitrary
>means, then they correspond to some virtual machine, 

I suspect it corresponds to a number of different virtual machines.
At least I don't know what notion of "the same" you would use to 
make them all be the same, except that they all come from the same
langauge.

>and can be compiled
>into either (1) a host language program that is forced to produce or pass
>through the states of the virtual machine specified by the source language
>(in the worst case you could make those states into output),

In what way is it forced to go through them?  I really don't
understand why you think this happens.  All compilers have to
do is to make sure that any deviations from the model don't
make any difference to the program.  That's why compilers can
optimize.  For instance, the language might say that arguments
to precedures are evaluated from left to right.  But the compiler
might notice that none of the argument expressions involve side
effects and it might then arrange for them to be evaluated in
a different order that's more efficient.

But even if there aren't optimizations, why should there be just one
VM per language?  ANSI C seems to be defined more or less in terms
of a virtual machine, but do you think that's the only virtual machine
that could fit the language?

> or into (2) a
>completely different program suitable to the host language, that produces
>the same result without regard to states. In the first case, the compiled
>program can also either be (1-opt) optimized to eliminate some states or
>replace some sections with other sequences of states that give the same
>result, or (1-plain) be left as is.
>
>Case 1-plain is of course the one that fulfills the strict definition of
>implementation I described inthe previous message, as there is a state-
>to-state-correspondence between the "physical" machine constituted by the
>host language program and the virtual machine.

The idea that this is "the strict definition of interpretation" is
somewhat strange.

>Case 2 obviuosly does not, since the program was converted into a completely
>other algorithm, or not even any algorithm at all, with the only thing in
>common being the output produced. It would be a murder of words to claim that
>both programs are representatives of the same algorithm, even though they
>solve the same problem. Performing two actions in opposite orders, makes
>two different algorithms, not one, though possibly both serving the same
>purpose. Case 2 thus would not be an implementation in the mentioned, strict
>sense.

I'm astonished.  A compiler swaps the order of some evaluations and
suddenly it's not producing implementations of algorithms specified
in the language it compiles?

In any case, my idea of an algorithm is more abstract than yours.
I think I can often write the same algorithm in, say, C and Prolog
even though the way they do things is quite different.

>Case 1-opt is actually similar to case 2 as far as algorithm identity goes,
>even though it may have preserved some states that correspond to the source
>program. As long as the optimizations are large enough that they affect the
>virtual machine states, it can't strictly be said to be the same algorith, at
>most it may be a variation on the same class of algorithms (the class of
>algorithms being defined by the results they produce). Case 1-opt thus too,
>would not be an implementation in the mentioned, strict sense.

As Dave Chalmers pointed out to me, it's not just the I/O.  Efficiency
also matters.  For example, an O(n) algorithm ought to be O(n).  Now,
I would have thought that quicksort was an example of an algorithm.
But according to you that's not so?

>Now, clearly there are also languages that in no way specify any algorithm,
>but rather only specify the result without bothering about exactly how that
>results is to be obtained. (Just look at some mathematical statement, that
>you are required to prove.) 

What language do you think specifies exactly how the results must be
obtained?

>More and more procedural languages are also being
>viewed this way, as a specification, although expressed in procedural terms,
>of what results to produce, that may actually be compiled into whatever gives
>the same result. It should be obvious that this is not the same as just
>straightly translating an algorithm from one algorithmic language into
>another. 

But whoever said it was the same?

Nonetheless, a compiler can work by translating one language to
another.  For instance, the KCL Common Lisp compiler compiles
Lisp by translating it into C.  

>It is possible to discuss whether or not to extend the meaning of "imple-
>mentation" to cover these other cases too. It usually does cover them. One
>could speak of "implementing an algorithm" and in the extended case more
>generally of "implementing a program" (by in turn implementing one of the
>algorithms that solves the program). Discussing what words to use for a
>certain phenomenon is not a very interesting question, though. Be aware
>though, that the extended meaning does not seem to have been the one David
>Chalmers chose to elaborate on.

What his view seems to come down to is that I may not be able to
write a program and be sure that every comforming compiler for the
language I write it in will actually produce the right state
transitions.  So in practice, I wouldn't be able to write my
understanding program in, say, Lisp or C.  I'd have to use some
much more restricted language or use only certian compilers.
This seems a very odd form of "strong AI" to me.

>>it can even be done for impure Lisp by explicitly representing
>>the store.  (Think of denotational demantics, e.g.)
>>
>>Moreover, compilers are allowed to cheat, so long as no one can tell.
>
>Yes. So what? They're not using the strict sense of "implement". Who claimed
>to describe everything a compiler might do, in this philosophy discussion?

Yes.  That's why it's in comp.ai.philosophy.

>>For instance, there might be a rule in the semantics to the effect
>>that memory is in a certain well-defined state at certain sequence
>>points.  But so long as nothing depends on some detail of this state
>>being right, it doesn't have to be right.
>
>Yes, that is an example of using a virtual machine definition to describe
>the meaning of the components of a language, without requiring that the
>compiler actually implement (in the strict sense) that machine.

Does anyone ever reauire that compilers implement the machine>

>>>Now, I think that the sense of "implement" David Chalmers has in mind
>>>here, is one where each state of the "physical" system that implements
>>>the algorithm in question, can be identified with one and only one state
>>>of the virtual machine as specified by the language, and the transitions
>>>from one of the states so identified to another one, exactly follow the
>>>execution steps specified by the algorithm, just as in the finite state
>>>machine case.
>>
>>I don't think a language specified a unique virtual machine.
>
>No? What do you call your own example with "well-defined state at certain
>sequence points" then?

I call it part of the description of _a_ virtual machine, not of _the_
virtual machine, for a language.

>Describing the actions of all elements of a language on the virtual machine
>of that language, is a way of defining the semantics of that language. And
>I think it is a good way to do it: exact, and easy to understand and picture
>in your head. I've even seen it done for 

I think it's a good way to define things too.

>You may be right about some non-procedural languages on that point though,
>if they genuinely do not specify any particular order of execution or
>evaluation. In that case you may have a language that can give you different
>results for the same program, depending on which compiler you use, since the
>compiler writer is then free to choose his own order of evaluation, unless
>you are very careful to guarantee that the order doesn't make any difference.

If the language specifies an order, the compiler can reorder only
when safe.

Many languages don't sepecify the order of evaluation of the arguments
to procedures.  Scheme and C are examples.  But then the language
definition ususally says conforming programs can't depend on the order.

>As regards to uniqueness, how would you propose to define more than one
>virtual machine for the same procedural language, all equivalent to each
>other as far as the language semantics goes, at least if you constrain
>yourself to not adding useless objects in them, and swapping names between
>its objects and such? Anyway, if the virtual machine (or equivalent) is
>part of the language definition, then obviously, that is THE virtual
>machine, no matter how many other ways you could have constructed it.

If the language has degrees of freedom in implementation, it should
also have degress of freedom in virtual machines.  I think there are
a number of examples in Lisp.  For instance the semantics might be
specified in terms of an SECD machine, but no one expects that real
implementations would have to correspond directly to SECD machine
operations.  The same dialect of Lisp might be defined in terms of
a more conventional virtual machine (as if it were a C program).

-- jd


