Re: Recursive printing errors

[gb@digitool.com (Gary Byers)]

At 03:56 12/19/94 -0500, Andrew.Mickish@A.GP.CS.CMU.EDU wrote:
>Have you had any other complaints about "recursive printing errors" in MCL?
>While I was developing Garnet in MCL, I would get these horrible errors
>scrolling infinitely in my listener frequently.  I would usually get them
>whenever I tried to load a library file or execute a trap instruction.
>Now our users of Garnet are getting them.
>
>I sent a bug report in about this last spring, but was never able to put
>together a small example.  Before I spend more time on this, I wanted to
>ask if you had any advice about it.
>
>Thanks,
>
>--Andrew Mickish
>
>
>-------------------------------- forwarded message -------------------------
>
>Date: Fri, 16 Dec 1994 11:14:42 +0500
>To: garnet-bugs@cs.cmu.edu
>From: tsl1@cornell.edu (Timothy S. Larkin)
>Subject: Garnet 3.0 and MCL
>Status: RO
>
>This message follows up on my earlier one about the failure of Garnet to
>load in MCL 2.01. It appears that Lisp is broken by this package
>definition:
>
>(defpackage :COMMON-LISP-USER (:use :COMMON-LISP #+apple :CCL
>                                    :KR :KR-DEBUG :GARNET-DEBUG)
>
>As evidence, I find that I can evaluate
>
>          (ccl::require-interface 'types)
>
>before evaluating the defpackage, whereas after the defpackage, the
>require-interface form produces
>
>> Error: There is no package named "NIL" .
>> While executing: #<error printing #<Recursive printing error> #x156334A>
>;  NOTE:
>> Error: There is no package named "NIL" .
>> While executing: #<error printing #<Recursive printing error> #x156334A>
>
>until the stack overflows.
>
>I haven't yet figured out why the package definition produces this disaster.
>
>
>Cordially,
>
>timothy larkin
>tsl1@cornell.edu

Some parts of the MCL runtime system - including parts that try to establish
that the environment is "reasonable" when an error is signalled - assume that
a package named "CL-USER" exists.  The #<recursive printing error>s are
symptoms of this assumption being violated.

The results of applying DEFPACKAGE to an existing package are undefined if
the new definition is not "consistent with the current state of the package."
MCL's implementation of DEFPACKAGE treats the case of unspecified (:NICKNAMES)
the same way that it treats a specified but empty set of (:NICKNAMES).
(One could argue that it would be better to distinguish between these cases;
one could as easily argue that using DEFPACKAGE to "redefine" a
built-in package like COMMON-LISP-USER isn't necessarily a good idea ...)

#+implementation-has-common-lisp-user-package
(eval-when (:compile-toplevel :load-toplevel :execute)
  (use-package '("KR" "KR-DEBUG" "GARNET-DEBUG") "COMMON-LISP-USER"))

#-implementation-has-common-lisp-user-package
(defpackage "COMMON-LISP-USER" (:USE ... ) (:NICKNAMES "CL-USER") ...)


Whether or not it's a good idea to trust that no symbols inherited by an
implementation's COMMON-LISP-USER package conflict with external symbols
of the "KR" "KR-DEBUG", and  "GARNET-DEBUG" packages is left as an exercise.

______________________________________________________________________________
Gary Byers
Digitool, Inc.
gb@digitool.com