ok@quintus.UUCP (Richard A. O'Keefe) (03/31/88)
In article <135@balder.esosun.UUCP>, kobryn@esosun.UUCP (Cris Kobryn) writes: > There are obvious tradeoffs between backward compatibility and syntactic > elegance. However, I don't think that the conversion problems you fear > being caused by the BSI standard are especially scary. Automatic conversion > programs are no panacea, but _can_ (in moderation) be useful here. > > With the perspective of several years it seems clear that Common Lisp > overemphasized compatibility at the cost of elegance. BSI seems to be > doing a much better job of this. > > -- Cris Kobryn Just a quick question: how many of the BSI documents have you read? (1) Since my proposed scheme involves plugging in a whole new reader, there would be *zero* compatibility cost. In fact, Kobryn's warning against "compatibility at the cost of elegance" is an argument on my side. The BSI group are making an attempt to provide some level of syntactic compatibility, and it's getting them into all sorts of trouble. If they would simply define what a conforming processor does with certain data structures, and let me plug in the reader of my choice, they could make up whatever new syntax took their fancy. They're already doing this: there is a Lisp-like syntax and a Prolog-like syntax. Why not let me plug in a third: DEC-10 syntax? Or why not let the BIM people plug in a fourth: BIM syntax? (2) There are all sorts of conversion problems with the BSI substandard. Many of them are syntactic, and many of them are semantic. BSI Prolog and "Edinburgh" Prolog are to each other much as Oberon (Wirth's latest) and Pascal are. (If you don't know about Oberon, substitute Modula-2.) Would you trust an automatic Pascal to Oberon translator? Would you like to buy a used bridge? It is theoretically *impossible* to write a *correct* automatic conversion program for Prolog or Lisp. It is practically possible to get a 99% one, but someone who understands the program to be converted enough to maintain it has to inspect the output *carefully*. It's not that I regard the conversion problems as *scary*. What I think they are is *costly* and *unwarranted*. 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. I think it's a good idea to have type tests which are logically sound. But I don't think it's a good idea to use the names of existing non-logical operations for them. For example, the following fragment is currently legal: succ(X, Y) :- ( integer(X) -> X >= 0, Y is X+1 ; integer(Y) -> Y > 0, X is Y-1 ; must_be_integer(X, 1, succ(X,Y)), must_be_integer(Y, 2, succ(X,Y)) ). {must_be_integer/3 is in the Quintus Prolog library; it is for reporting errors.} Suppose I call succ(123, X) where X is a variable. Currently, I get the answer X=124. In BSI Prolog I'd get an error message. Conversion is NOT going to be easy. Now, if only they had defined is_integer/1 the way they want it, I could convert my programs by adding integer(X) :- fail_if(var(X)), is_integer(X). {I can't use nonvar(X), because nonvar/1 is not in BSI Prolog.} This change to the meaning of atom/1 and integer/1 is so unfortunate and so unmotivated (the type_of/2 predicate which is also in BSI Prolog was introduced in PS/6 back in 1984 to provide sound type testing), that I have to back up my claim that this is so. Anyone who looks at older drafts of the fragments, such as PS/172, will see that up till that point, the familiar behaviour was preserved. I can't find my copy of PS/201, but PS/230 defines compound/1 thus: 15.14 compound/1 Note BSI Reference: P037-871124 Note Changes will be required when a decision has been taken whether or not to allow variable functors. 15.14.1 Description. compound(X) succeeds iff X is a compound term. 15.14.2 Definition. compound(X) :- functor(X, _, N), % my note: no preceding nonvar(X) N \= 0. % my note: that's \=, not =\= 15.14.3 Errors. (a) X a variable (instantiation fault) 15.14.4 Examples compound(33.3). Fails compound(_). Instantiation fault compound(a). Fails compound(a(b)). Succeeds Note PS/6 has a predicate callable(X) :- atom(X) ; compound(X). which maybe we should add. PS/210, the Formal Specification, is quite clear: ATOM/1 formal definition is-a-type-testing-bip ( pred ( atom, _.nil ) ). execbip ( _, pred ( atom, X.nil ), empsubs ) <= is-an-atom ( X ). error definition in-error ( pred ( atom, X.nil ), undef-message) <= L-var ( X ). 3.27) atom definition --------------------- is-an-atom ( func ( N, nil ) ) <= L-atom ( N ). All the type testing predicates are thus defined in PS/210. {The spaces around parentheses are there in PS/210; they're not mine} If the BSI group were really so concerned about soundness, would they have added (\=)/2, which is UNSOUND inequality? Get this straight: I'm not objecting to the BSI group adding sound type tests. NU Prolog has them, and I __like__ NU Prolog. What I object to here is using the names of existing operations and giving them a different meaning. Sure, an automatic conversion program can be written which replaces atom(X) by (fail_if(var(X)) & atom(X)) PROVIDED that it can figure out where this was a type test contrasting with integer(X) and where it was data contrasting with molecule(X). [If anyone has a a program which can figure this out for BSI Prolog, I would be very interested to see it. Chris Moss says that he thinks the second argument of bag/3 is a data position and that he wants the grammar to reflect this, so we can't make the same distinctions as the grimoire does or we'll miss some.] A conversion program is likely to miss cases like ?- maplist([atom,integer], [X,Y]). If the BSI group don't like existing operations, that's FINE, as long as they leave the things they don't like undefined, and use new names for new things, and provide a sufficient basis for writing compatibility packages. Changes like this one leave a very nasty taste in the mouth.