Re: Scheme broken on OZ today.

[David C. Plummer <DCP at MIT-MC>]

You want to make separate code and data spaces for the current
MACLISP, do you??  Well, FORGET IT!!!  Perhaps you should get
Gorin's book on TWENEX assembler and read the section on extended
addressing.

Basically, CAR and CDR won't work.  Well, it might have a prayer
if the CODE for CAR and CDR were in the DATA section.  This goes
for all other code that does a CAR or CDR.  Well, then again, you
might be able to get around that by making CAR and CDR be two
instructions instead of one.  The second instruction would set
the left half to be the DATA section.  Kludge, kludge, kludge.
Now what about all those other primitive LISP operators??

That is not the right solution.  The right solution is to
reimplement 'Lisp' for extended addressing machines.  For 2060's
this would give you 31 address spaces (assuming you can't do much
useful stuff in section 0).  On the Jupiter I think the number
jumps to 4095 (and then all you need is several dozen disk drives
for paging).

I know of at least one effort to write an extended addressing
superset of Common Lisp.  How much MACLisp code will need to be
modified or rewritten probably depends on how well it was written
for portability in the first place.

My feable knowledge of Common Lisp forces me to make the
following warnings:  

* Expect your programs to get bigger.  CONSes will take up two
  words instead of one.
* Fixnums may shrink to 32 (or even 30) bits.  Overflow will cons
  bignums. 
* Expect arithmetic operations to slow down.  I think Common Lisp
  does generic arithemetic.  If so, a simple + on non-declared
  numbers needs to check the arguments and value (even in compiled
  code).