🚀 go-pugleaf

In article <841@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>Yes, it *is* theoretically impossible to write a correct automatic conversion
>program from Lisp to assembler.  You have to have an interpreter as well.
>Why?  Because you can construct code on the fly and execute it.

I take your point, Richard, but it's worth pointing out that you don't
need an interpreter per se: you can just keep the translator around.

>Unfortunately, because Lisp has EVAL and Prolog has call/1, whether a
>particular instance of some term will be called or used as data is not a
>simple syntactic property.  It's at least as hard as solving the halting
>problem.  (In fact, a term may be used as BOTH code and data.)

Scheme (which is after all a dialect of Lisp) doesn't have EVAL in
the R3 Scheme Report in part because they want to prevent arbitrary
data being turned into code.

It's interesting that call/1 in Prolog is basically an EVAL, while
Lisp has EVAL but also a less troublesome notion in APPLY.  

>> Prolog is a relatively new language.  Why should we expect its form to
>> be frozen in stone so soon.

Note that this is an argument that Prolog is not ready to be standardized,
not that the standard should be for an improved Prolog.  Unfortunately (for
that argument), people would very much like to have a standard now rather
than wait for Prolog to develop into something better.

>The point of a standard is precisely to freeze the state of the art so that
>people who are interested in USING something can get on with the job,
>secure in the knowledge that they have a workable definition of what their
>tools are supposed to do.

Just so.

But there's a problem with this view, and I think both the Lisp and Prolog
standardization efforts have encountered it.  The problem is that some
parts of the existing language do not, to some people, seem worthy of
standardization.  And so long as we're standardizing, they say, we may
as well clean things up a little.  These things may have been ok for an
individual implementation, they add, but a standard must meet higher
standards...

This sort of thing is fine to a limited extent.  Where different
implementations disagree, there has to be some adjustment.  But when such
changes amount to designing a new language, it is certainly legitimate to
complain that they have gone too far.

Whether the BSI changes do amount to designing a new langauge is another
matter, but one on which others are better qualified to comment than I.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton