Re: ASSERT, ports, and NIL

[David Bartley <Bartley%ti-csl.csnet@csnet-relay.arpa>]

I'd like to clarify my dilemma concerning NIL.  Jonathon Rees has shown,
correctly, that one has no problem meeting both the Common Lisp and
standard Scheme specifications for the empty list when the Scheme developer
is able to affect the implementation of both languages.  In that case, the
underlying representation for the empty list is arbitrary (call it #!NULL).
The Scheme reader treats the token NIL as a symbol.  The Common Lisp reader
interns the token NIL as #!NULL, and such critical routines as SYMBOLP and
INTERN are modified to pretend that the value named #!NULL is a symbol.

The situation I am concerned about is one in which Scheme is being
implemented on top of an existing Lisp system which we are unable to
modify.  This is clearly a short term problem, but quite real while it
lasts, and surely not unique to us.  For example, it is a problem with
Scheme implementations in Franz Lisp, and in ZetaLisp on Lisp Machines with
()==NIL hardwired into microcode.

Let me walk through an instance of the problem.  Assume an existing Lisp in
which ()==NIL.  In Lisp, generate a list; the list will be "terminated"
with the symbol NIL in the last CDR.  Pass the list to a Scheme routine,
which cdr's down it until it reaches -- what?  Unless #!NULL==NIL, Scheme
can't detect the end of the list with a simple EQ? test.  Sharing of list
data between the two languages is effectively ruled out.

Again: I'm not arguing that allowing #!NULL==NIL is "good," because it
certainly isn't.  I'm just asking for help in overcoming it and, barring a
true solution, insertion of appropriate language in the revised revised
Report acknowledging that it may be a necessity in some implementations.

Alternatively, we could consider such an implementation a "near Scheme" and
take the long term view that it is an interim step towards a "true Scheme."
My purpose here is to raise the issue and possibly find a solution I hadn't
thought of, not to quibble over legalities.

Regards,
David Bartley
-------