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: compatibility/elegance & *theory*
Message-ID: <136@vor.esosun.UUCP>
Date: 31 Mar 88 18:57:52 GMT
Organization: SAIC, San Diego
Lines: 78



After reading Richard O'Keefe's response to Cris Kobryn's article, I would
like to make a *few* points...

	First of all, I agree with the idea of being able to plug in
different readers -- however, I don't think this is the area of
compatibility to which Mr. Kobryn was referring.  The chief problems
with CommonLisp (according to me) are semantic, not syntactic.  The
CommonLisp designers payed too much attention to the M**lisp and
Z***lisp communities who moaned and whined about the AWFUL cost of
updating old code. 

>>    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... 


>>  For example, in Prolog-as-we-know-it,
>>      atom(X)
>>  fails quietly if X is a variable.  This is not terribly logical,
>>  but that is the way it has always been, and people have written
>>  their programs assuming that that's the way it works.  Even NU
>>  Prolog, which supports coroutining in a particularly nice way,
>>  doesn't change that.  (NU Prolog has isAtom/1, which IS logical.)
>>  Come to that the equivalents in VM/Prolog and Waterloo Prolog are
>>  similar.  But in the current BSI fragments, we find that
>>      atom(X)
>>  will report an ERROR if X is a variable.


Prolog is a relatively new language.  Why should we expect its form to
be frozen in stone so soon. It's hard to think in terms of "the way it
has always been" with regard to Prolog. I have a sneaking suspicion that
"Prolog-as-we-know-it" will probably change quite a bit in the
future.  It's a shame that code might need to be re-written, but, do we
want to burden future generations of logic programmers with today's
short-sightedness?  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?".



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.

How many times have I heard...

"But, we have too much COBOL code that already works -- we can't change now"

or,

"But, Fortran does everything I need..."

or even,

"BASIC is just fine.. after all, all languages are Turing-machine equivalent"


In some ways, these are extreme examples but, on the other hand, they
are less extreme because the changes that these folks are fighting are
far more pervasive and difficult than a few rather subtle changes.


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.


--Jerry Jackson