🚀 go-pugleaf

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