Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: compatibility/elegance & *theory* Message-ID: <841@cresswell.quintus.UUCP> Date: 1 Apr 88 06:09:34 GMT References: <136@vor.esosun.UUCP> Organization: Quintus Computer Systems, Mountain View, CA Lines: 131 In article <136@vor.esosun.UUCP>, jackson@esosun.UUCP (Jerry Jackson) writes: > After reading Richard O'Keefe's response to Cris Kobryn's article, I would > like to make a *few* points... A fair summary of what he says is "---- the users". > >> It is theoretically *impossible* to write a *correct* automatic > >> conversion program for Prolog or Lisp. > What an interesting statement.... Is it also theoretically *impossible* to > write a *correct* automatic conversion program from Lisp to assembler? > Somehow, this seems like a similar problem to me... 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. The problem with automatic conversion from dialect X of Lisp (or Prolog, or Pop) to dialect Y is that you need an interpreter for dialect **X** around at run time, but what you get is an interpreter for dialect Y. I gave an example of this problem. You don't even have to be able to construct arbitrary chunks of code at run time, it is enough to be able to call a predicate whose identity cannot be determined without running the code (or, to be pedantic, without doing something approximately as costly). I gave an example in my previous message. Here's another one: ordered(Test, List) :- ordered_1(List, Test). ordered_1([], _). ordered_1([Head|Tail], Test) :- ordered_1(Tail, Head, Test). ordered_1([], _, _). ordered_1([Head|Tail], Prev, Test) :- call(Test, Prev, Head), ordered_1(Tail, Head, Test). descending(List) :- ordered(compare(>), List). In order to convert this to some other dialect, (a) the effect of compare(>, X, Y) must be available somehow. (b) the translator must be smart enough to know that it is ok to replace THIS instance of compare(>) by some other term, whereas other instances of compare(>) are data and should not be changed. 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.) > Prolog is a relatively new language. Why should we expect its form to > be frozen in stone so soon. Because that's what a standard ***IS***. I started using DEC-10 Prolog in 1979, and I think it had existed for over a year before I first saw it. A language which is ten years old is hardly "relatively new". Pascal wasn't much older when it was standardised, and ADA was *born* standardised. > In this particular example, (which I consider a > strange one for Mr O'Keefe to use to make a point), it seems to me > that the BSI behavior is much more sensible.. after all, does it > really make sense to ask the question: "Is this unknown object an > atom?". Jackson has managed to completely ignore my point. I too explicitly said that the BSI behaviour is more "logical". I explicitly said that they could add a new is_atom/1 predicate similar to NU Prolog's isAtom/1 with my good will. What I objected to was them CHANGING the definition of atom/1. Look, all they have to do is leave atom/1 out of the standard entirely, and define in its place is_atom/1 doing what they and Jackson want it to. If var/1 makes sense (and it IS in the BSI fragments), then the existing atom/1 makes sense. My message included an example where the fact that integer/1 fails for variables makes sense. But that's not the point at issue. The point is that the BSI group *could* have provided the feature they wanted in a way that would have made it possible for people to write compatibility packages and would have significantly reduced the cost of conversion, and by doing so they could have followed in the footsteps of NU Prolog which already has this feature, but they chose not to do so. > I'm sure Mr. O'Keefe has some valid complaints about the semantics of > BSI.. (I haven't read the grimoire), but I fear many of his complaints are > grounded in a desire to avoid the (admittedly painful) task of upgrading > code. I read that as implying that I wanted to avoid changing MY code. (BSI Prolog is hardly an improvement on anything, so you couldn't call it "upgrading".) That is not the case. I don't intend to change any of my code. What I am worried about is paying customers. > Finally, do we want people 20 years from now thinking about Prolog the > way most people think about Fortran today. This is what will happen > if we concern ourselves too much with compatibility at this early > date. I want people 20 years from now thinking about Prolog the way most people think about Autocoder. Interesting, influential, useful in its time, but long since surpassed. Actually, come to think of it, I wouldn't mind too much if people DID think of Prolog as being like Fortran. I don't _like_ Fortran, but at least I know what it does, and CALGO, JCAM, CJ, AS, LINPACK, TSPACK, ... and many other collections of useful algorithms are in Fortran, so as long as a Fortran processor does what the standard says it does, it can be of use to me whether I know Fortran or not. When it comes to cooking a meal, I'd rather have an ugly old frying pan that works than a shiny new one with no handle. 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. Jackson quoted COBOL. Well, I've news for him. Successive versions of the COBOL standard have been dramatically different. It took *years* after the introduction of COBOL 74 before many sites had upgraded, and the conversion was barely finished when COBOL programmers were hit with a NEW standard which had still more dramatic differences. Jackson quoted FORTRAN. Has he seen a draft of Fortran 8X, I wonder? Having a standard which has been ratified in a particular year does not freeze the language for all time. I keep trying to get this point across, and seem to keep failing: - DESIGNING a language is one thing, with one set of criteria. - STANDARDISING a language is another thing with another set. - Just because there is a standard for a language doesn't mean you can't design a new language, only that your new language isn't the existing standard.