GETPR and compatibility

[Kim.fateman at Berkeley]

There are (at least) two kinds of compatibility worth comparing.

1. One, which I believe is very hard to do,
probably not worthwhile, and probably not
in the line of CL, is the kind which
would allow one to take an arbitrary maclisp (say) file, read it into
a CL implementation, and run it, without ever even telling the CL
system, hey, this file is maclisp.  And when you prettyprint or debug one of
those functions, it looks pretty much like what you read in, and did
not suffer "macroâ??replacementâ??itis".

2. The second type is to put in the file, or establish somehow,
#.(enter maclispâ??mode)  ;; or whatever, followed by
<random maclisp stuff>
#.(enter commonâ??lispâ??mode)  ;; etc.

The reader/evaluator would know about maclisp. There
are (at least) two ways of handling this
  a:  any maclisp construct (e.g. get) would be macro-replaced by
the corresponding CL thing (e.g. getprop or whatever); arguments would
be reordered as necessary.  I think transor does this, thought generally
in the direction non-interlisp ==> interlisp.  The original maclisp
would be hard to examine from within CL, since it was destroyed on read-in
(by read, eval or whatever made the changes). (Examination by looking
at the file or some verbatim copy would be possible).  This makes
debugging in native maclisp, hard.
  b: wrap around each uniquely maclisp construction (perhaps invisibly)
(evaluateâ??asâ??maclisp  <whatever>).  This would preserve prettyprinting,
and other things.  Functions which behave identically would presumably
not need such a wrapper, though interactions would be hard to manage.

I think 2a is what makes most sense, and is how Franz lisp
handles some things which are, for example, in interlisp, but not in Franz.
The presumption is that you would take an interlisp (or maclisp)
file and translate it into CL, and at that point abandon the original
dialect.  In view of this, re-using the names seems quite possible,
once the conversion is done.
  In point of fact, what some people may do is handle CL this way.
That is, translate it into  another dialect, which, for whatever
reason, seems more appropriate.  Thus, an Xlisp chauvinist
might simply write an Xlispifier for CL. The Xlispifier for CL
would be written in Xlisp, and consist of the translation package
and (probably) a support package of CL functions.  Depending on
whether you are in CL-reading-mode or XL-reading-mode, you would
get one or the other "getprop".
  Are such "implementations of CL"  "correct"?  Come to think of
it, how would one determine if one is looking at an implementation
of CL?