[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redefinition of print-object
- To: firstname.lastname@example.org
- Subject: Re: Redefinition of print-object
- From: Joachim Schrod <email@example.com>
- Date: Mon, 18 Jul 1994 20:21:52 +0100 (MESZ)
- In-reply-to: <9407161223.AA08673@ma2s2.mathematik.uni-karlsruhe.de> from "Bruno Haible" at Jul 16, 94 02:25:59 pm
> > WARNING:
> > The generic function #<GENERIC-FUNCTION PRINT-OBJECT> is being modified, but has already been called.
> > I would like to know if this might be a problem with my installation.
> Not at all. The function PRINT-OBJECT is called when lispinit.mem is
> built (on objects of type CONDITION), and the info that it has been called
> is remembered in lispinit.mem.
> I am a bit unhappy about this warning because PRINT-OBJECT is meant to
> be extended even after having been called, but I don't see in which
> respect PRINT-OBJECT is special among all generic functions.
It seems to be my turn for the weekly enhancement wish... :-) :-)
The background: It concerns CLOS language extensions or installation
of applications. In both cases the user works with a virtual platform
that should be `clean' for him. I get mails from users that want to
install an application and ask now if something went wrong. (Yes,
they're no Lisp programmers -- real (l)users...)
Of course, the quick fix is to add this to the documentation. But
then, who reads documentation? And so I would like to get rid of this
(a) An additional argument to #'saveinitmem that tells CLISP that all
definitions are clean (i.e., not used).
That can be used if this memory image shall be a virtual
machine where the user shall not see its internal structure. The
default of this argument is nil.
(b) some global variable (in package system?) that controls the
output of such warnings. (And that I can turn off in my
(c) Some way to tell #'load that it shall not issue such a warning.
Perhaps via the value of verbose? Or an additional keyword parameter?
I must say, I like (a) since it matches exactly my usage of Lisp. (c)
is IMO problematic since it's outside dpANS (is it?).
Joachim Schrod Email: firstname.lastname@example.org
Computer Science Department
Technical University of Darmstadt, Germany