*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