*start*
00790 00024 US 
Date: 13 Apr 88 13:46 PDT
Sender: Lanning.pa
From: Stanley's Tool Works <Lanning.pa>
Subject: Re: [darrelj%sm.unisys:COM: Interlisp to Commonlisp conversion package]
In-reply-to: masinter.pa's message of 12 Apr 88 11:22 PDT
To: masinter.pa
cc: LispUsers^.x

Beware loading this utility.  Here's one way to lose.

A side effect of this utility is that the var CLISPARRAY is set to NIL.  As a result, all CLISP translations are stored not in a hash array; instead the source form is smashed to some specially tagged list that contains the CLISP source and the translation.  This construct is understood by the interpreter and the byte-compiler, but *not* the new compiler.  As a result, compiling any code with, say, (fetch ...)'s in it produces garbage. 


----- smL
*start*
02329 00024 USa
Return-Path: <darrelj@sm.unisys.com>
Received: from rdcf.sm.unisys.com (SM.UNISYS.COM) by Xerox.COM ; 02 MAY 88 15:55:29 PDT
Received: by rdcf.sm.unisys.com (sdcrdcf) (5.51/Domain/jpb/2.9) 
	id AA03568; Mon, 2 May 88 15:56:12 PDT
Message-Id: <8805022256.AA03568@rdcf.sm.unisys.com>
Received: from XERXES by sdcrdcf with PUP; Mon, 2 May 88 15:56 PDT
From: darrelj@sm.unisys.com
Date: 2 May 88 15:55 PDT (Monday)
Subject: Re: comments on Transor
In-Reply-To: Masinter.pa@Xerox.COM's message of 1 May 88 22:35 PDT
To: Masinter.pa
Cc: darrelj@sm.unisys.com, Lanning.pa

   Date: 1 May 88 22:35 PDT
   From: Masinter.pa@Xerox.COM
   Subject: comments on Transor
   To: darrelj@sm.unisys.COM
   Cc: Lanning.pa@Xerox.COM
   Message-Id: <880501-223544-2658@Xerox>

   Is it necessary to set CLISPARRAY to NIL?

   00790 00024 US 
   Date: 13 Apr 88 13:46 PDT
   Sender: Lanning.pa
   From: Stanley's Tool Works <Lanning.pa>
   Subject: Re: [darrelj%sm.unisys:COM: Interlisp to Commonlisp
   conversion package]
   In-reply-to: masinter.pa's message of 12 Apr 88 11:22 PDT
   To: masinter.pa
   cc: LispUsers^.x

   Beware loading this utility.  Here's one way to lose.

   A side effect of this utility is that the var CLISPARRAY is set to NIL.  As a
   result, all CLISP translations are stored not in a hash array; instead the
   source form is smashed to some specially tagged list that contains the CLISP
   source and the translation.  This construct is understood by the
   interpreter and
   the byte-compiler, but *not* the new compiler.  As a result,
   compiling any code
   with, say, (fetch ...)'s in it produces garbage. 


   ----- smL

Its only necessary to set CLISPARRAY to NIL if you want translations
of Clisp to common Lisp :-).  The TRANSOR scan needs to have the stuff
inline to traverse the clisp expansions of stuff like fetch and for
(in some cases).
I lived with this by a combination of using old compiler for the
transformation code, and setting CLISPARRAY to a new hash array when
done with a session of translation (if you hand set it to NIL, you can
even save the old value for later).
In principle I guess it could be made to not follow the hash pointers,
but the use of the Teletype editor by Transor is messy and closely
intertwined in ways I don't entirely understand.
	Darrel