Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!ucsd!sdcsvax!ucsdhub!esosun!jackson From: jackson@esosun.UUCP (Jerry Jackson) Newsgroups: comp.lang.prolog Subject: Re: compatibility/elegance & *theory* Message-ID: <137@vor.esosun.UUCP> Date: 1 Apr 88 17:23:19 GMT References: <136@vor.esosun.UUCP> <841@cresswell.quintus.UUCP> Organization: SAIC, San Diego Lines: 108 In-reply-to: ok@quintus.UUCP's message of 1 Apr 88 06:09:34 GMT In response to my previous posting, Richard O'Keefe has had some interesting things to say: >> A fair summary of what he says is "---- the users". no comment. >>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. Golly, so you need an interpreter too? Having written a couple of Lisp interpreters, a couple of subset Lisp compilers, and a couple of Prolog subset interpreters, I never would have guessed that. So why can't the interpreter be part of the translation... Can you say 'action routine'??? For your information, most compilers have pieces of *pre-written* code that are used to implement certain operations... In any case, the original statement that prompted your *theoretically* *impossible* response merely stated that automatic conversion programs could be helpful -- not that they were the ultimate solution to compatibility problems. >> > 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. The "frozen in stone" that I was referring to was not the new developing standard (which does have 10 years behind it), but the defacto standard that O'Keefe has been pushing (DEC-10).. which had effectively NO history when it first became widely used.. >>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. No, I didn't ignore your point -- I simply disagreed with it. I feel that part of the purpose of creating a standard is to clean up the language by acting upon the experience of the user community -- even a language such as 'C' (which has MUCH more money and effort invested in pre-existing software), has gone through some changes in the course of standardization. (And 'C' is typically used in production environments where change is much harder to deal with than in the research oriented environments where most Prolog is still done). >> > 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. O'Keefe has managed to completely miss my point -- I consider Fortran (and Autocoder) to be major WINS for the time they were created... When I referred to the way people think about Fortran today, I wasn't referring to Fortran as an interesting historical artifact (which it is), but about the fact that inertia has managed to keep it in an objectionable state up to the present day... >>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. Apparently a grain-size problem occured here... I was referring to people changing FROM COBOL or Fortran to a computer language (that is why I mentioned that it was an extreme example) >>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. Who could argue with this? Perhaps the reason you keep failing to get your point across is that this really isn't the point you are pushing. --Jerry Jackson