perm filename CLOOPS.MSG[COM,LSP]11 blob sn#862528 filedate 1988-10-24 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00080 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00014 00002	
C00015 00003	∂16-May-88  1139	Common-Lisp-Object-System-mailer 	CLOS document numbers for June meeting   
C00017 00004	∂16-May-88  1524	Common-Lisp-Object-System-mailer 	Chapter 2  
C00018 00005	∂17-May-88  1340	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00020 00006	∂18-May-88  1101	Common-Lisp-Object-System-mailer   
C00022 00007	∂18-May-88  1818	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00026 00008	∂18-May-88  2007	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 2 (dated May 16 15:09)    
C00033 00009	∂19-May-88  1613	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00041 00010	∂20-May-88  1508	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00062 00011	∂20-May-88  1703	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
C00073 00012	∂20-May-88  2010	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00078 00013	∂20-May-88  2206	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00080 00014	∂21-May-88  0017	Common-Lisp-Object-System-mailer 	Mlynarik's comments  
C00092 00015	∂21-May-88  0651	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00099 00016	∂21-May-88  1602	Common-Lisp-Object-System-mailer 	define-method-combination 
C00106 00017	∂21-May-88  1605	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00109 00018	∂21-May-88  1923	Common-Lisp-Object-System-mailer 	define-method-combination 
C00118 00019	∂23-May-88  0644	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00123 00020	∂23-May-88  0842	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
C00131 00021	∂23-May-88  0948	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
C00133 00022	∂23-May-88  1047	Common-Lisp-Object-System-mailer 	More Check-Keyword-Arguments   
C00134 00023	∂23-May-88  1055	Common-Lisp-Object-System-mailer 	define-method-combination 
C00143 00024	∂23-May-88  1105	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
C00146 00025	∂23-May-88  1211	Common-Lisp-Object-System-mailer 	Define-Method-Combination 
C00148 00026	∂23-May-88  1234	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00149 00027	∂23-May-88  1537	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00151 00028	∂23-May-88  1539	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
C00154 00029	∂23-May-88  1600	Common-Lisp-Object-System-mailer 	check-keyword-arguments etc.   
C00156 00030	∂23-May-88  1633	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
C00157 00031	∂23-May-88  1649	Common-Lisp-Object-System-mailer 	Re: Mlynarik's comments   
C00160 00032	∂23-May-88  1659	Common-Lisp-Object-System-mailer 	Chapter 1  
C00161 00033	∂23-May-88  2332	Common-Lisp-Object-System-mailer 	Method Objects are not Functions    
C00162 00034	∂24-May-88  1044	Common-Lisp-Object-System-mailer 	Re: Method Objects are not Functions     
C00164 00035	∂24-May-88  1105	Common-Lisp-Object-System-mailer 	Callable Methods
C00166 00036	∂26-May-88  1055	Common-Lisp-Object-System-mailer 	with-added-methods   
C00170 00037	∂02-Jun-88  1329	Common-Lisp-Object-System-mailer 	[David N Gray <Gray@DSG>:  making structures] 
C00172 00038	∂20-Jun-88  1330	Common-Lisp-Object-System-mailer 	Compile-file environment  
C00179 00039	∂22-Jun-88  1448	Common-Lisp-Object-System-mailer 	SYMBOL-MACROLET-UTILITY   
C00185 00040	∂24-Jun-88  1225	Common-Lisp-Object-System-mailer 	which functions should be generic?  
C00187 00041	∂24-Jun-88  1332	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00189 00042	∂24-Jun-88  1545	Common-Lisp-Object-System-mailer 	which functions should be generic?  
C00192 00043	∂24-Jun-88  1648	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00197 00044	∂25-Jun-88  1204	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
C00202 00045	∂03-Jul-88  1051	RPG 	The Law of Demeter  
C00206 00046	∂11-Jul-88  1111	CL-Object-Oriented-Programming-mailer 	CLOS Workshop   
C00210 00047	∂15-Jul-88  1304	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00216 00048	∂15-Jul-88  1408	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00223 00049	∂15-Jul-88  1719	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles
C00228 00050	∂18-Jul-88  0808	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles     
C00231 00051	∂18-Jul-88  1307	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
C00242 00052	∂26-Jul-88  0847	Common-Lisp-Object-System-mailer 	where I'm going, etc.
C00247 00053	∂02-Aug-88  1412	Common-Lisp-Object-System-mailer 	declare in with-slots
C00250 00054	∂03-Aug-88  0712	Common-Lisp-Object-System-mailer 	RE: decalre in with-slots 
C00254 00055	∂03-Aug-88  0852	Common-Lisp-Object-System-mailer 	RE: declare in with-slots 
C00256 00056	∂03-Aug-88  1024	Common-Lisp-Object-System-mailer 	declare in with-slots
C00260 00057	∂03-Aug-88  1150	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00263 00058	∂03-Aug-88  1504	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00266 00059	∂03-Aug-88  1538	Common-Lisp-Object-System-mailer 	declare in with-slots
C00268 00060	∂04-Aug-88  0828	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00272 00061	∂04-Aug-88  1134	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00274 00062	∂05-Aug-88  1331	Common-Lisp-Object-System-mailer 	description language classes & the Meta-Object Protocol 
C00292 00063	∂05-Aug-88  1833	Common-Lisp-Object-System-mailer 	Re: description language classes & the Meta-Object Protocol  
C00294 00064	∂08-Aug-88  1020	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00300 00065	∂10-Aug-88  0952	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00307 00066	∂11-Aug-88  0810	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00313 00067	∂11-Aug-88  1021	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
C00321 00068	∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
C00325 00069	∂09-Sep-88  1203	RPG 	first part of mop   
C00329 00070	∂10-Sep-88  1150	RPG 	Re: first part of mop    
C00334 00071	∂12-Sep-88  1102	Common-Lisp-Object-System-mailer 	Fairfax Meeting 
C00336 00072	∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00341 00073	∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C00344 00074	∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00348 00075	∂14-Sep-88  1817	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
C00356 00076	∂15-Sep-88  1304	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
C00359 00077	∂15-Sep-88  1331	Common-Lisp-Object-System-mailer 	Re: call-next-method and arguments to :before and :after methods  
C00362 00078	∂20-Sep-88  1817	Common-Lisp-Object-System-mailer 	Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C00364 00079	∂20-Sep-88  2008	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C00367 00080	∂21-Sep-88  1423	Common-Lisp-Object-System-mailer 	metaobject protocol (description languages)   
C00371 ENDMK
C⊗;
∂16-May-88  1139	Common-Lisp-Object-System-mailer 	CLOS document numbers for June meeting   
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 16 May 88  11:37:59 PDT
Received: by labrea.stanford.edu; Mon, 16 May 88 11:37:44 PDT
Received: from sunvalleymall.lucid.com by edsel id AA25773g; Mon, 16 May 88 11:13:24 PDT
Received: by sunvalleymall id AA28381g; Mon, 16 May 88 11:16:26 PDT
Date: Mon, 16 May 88 11:16:26 PDT
From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
Message-Id: <8805161816.AA28381@sunvalleymall.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS document numbers for June meeting

CLOS chapters 1&2:	88-002R
CLOS chapters 3:	88-003R

∂16-May-88  1524	Common-Lisp-Object-System-mailer 	Chapter 2  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>


New Chapter 2 files are now available as functi.*[cls,lsp] on sail.
This material should now be up-to-date except for whatever we decide
to do with check-keyword-arguments.

Please send comments and corrections to me by Thursday morning.

-lgd

∂17-May-88  1340	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 May 88  13:40:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAY 88 13:38:44 PDT
Date: 17 May 88 13:38 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments   
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 May 88 13:56
 PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880517-133844-2742@Xerox>

    I have no worries that someone who is writing his own version
    of make-instance could look in chapter 3 or 4 to find out how to do
    error checking. Therefore, only a check-keyword-arguments that is
    more generally useful justifies going beyond specifying a
    procedural definition of make-instance that is reasonable only for
    correct invocations of it.

I am now satisfied that your more general version of check-keyword-arguments can
be useful.  It would be good to have this last issue for chapter 2
(check-keyword-arguments) settled, and am happy to have it as last specified.   

∂18-May-88  1101	Common-Lisp-Object-System-mailer   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 18 May 88  11:01:24 PDT
Received: by ti.com id AA20889; Wed, 18 May 88 07:13:51 CDT
Received: from Jenner by tilde id AA06761; Wed, 18 May 88 07:12:44 CDT
Message-Id: <2788949394-1458237@Jenner>
Date: Wed, 18 May 88  07:09:54 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU

Subject: Re: check-keyword-arguments   
In-Reply-To: Msg of 17 May 88 13:38 PDT from Danny Bobrow <Bobrow.pa@XEROX.COM>

     
     I am now satisfied that your more general version of check-keyword-arguments can
     be useful.  It would be good to have this last issue for chapter 2
     (check-keyword-arguments) settled, and am happy to have it as last specified.   

I agree.

Patrick.

∂18-May-88  1818	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88  18:18:27 PDT
Date: Wed, 18 May 88 21:22:40 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380679.880518.MOON@AI.AI.MIT.EDU>

1-12 fourth bullet: typos "an :documentation", "documentation documentation"

1-30 first bullet, also second dash bullet: These say an error is
signalled if call-next-method is called when there is no next method.
I thought we changed that to call a generic function whose name escapes
me at the moment, whose default method signals an error.

1-31 last bullet: ditto

1-35: Should the four simple mechanisms listed be augmented with
shared-initialize as a fifth bullet?

1-38 4th paragraph: maybe this should be "initialize-instance or
shared-initialize methods should be used instead."

1-39 penultimate paragraph: shared-initialize does not take three
arguments, it takes two required arguments plus a set of &key arguments.
The initialization arguments are passed as separate arguments, not as a list.

1-40 first paragraph after first three bullets: should be "whose first
parameter specializer is the class standard-object".

1-41 1st paragraph: same comment as 1-39.

1-41 last line: the parameter name is instance, not class, and the
parameter specializer is standard-object, not standard-class.

1-43 4th paragraph: There is a stray sentence fragment "the value
of the shared slot in the old class."  

1-43 6th paragraph: I think this should mention that the process can
also be triggered by an explicit call to the function make-instances-obsolete.

1-44 6th paragraph: Rather than saying update-instance-for-redefined-class
takes an &rest argument which is a list of initialization arguments, I
believe it is more correct terminology to say that it takes &key arguments
which are the initialization arguments.  The default method may receive these
with an &rest parameter, but the generic function's lambda-list says &key,
not &rest.

1-44 last paragraph: same comment as 1-39.

1-46 penultimate paragraph: same comment as 1-44 6th.

1-47 last paragraph: same comment as 1-39.

1-48 3rd paragraph: same comment as 1-44 6th.

1-48 last paragraph: same comment as 1-39.

∂18-May-88  2007	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 2 (dated May 16 15:09)    
Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 May 88  20:06:58 PDT
Date: Wed, 18 May 88 23:11:11 EDT
From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 2 (dated May 16 15:09)
To: Common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <380731.880518.MOON@AI.AI.MIT.EDU>

There is also one comment on chapter 1 in here.

2-6 first paragraph: I'm not sure what is meant by behavior intrinsic to a
generic function itself.  I think this probably means a contract that all
methods must obey (as distinguished from idiosyncratic behavior of one
particular method).

2-12: This says call-next-method signals an error, but I thought we
changed it to call a generic function whose default method signals an error.

2-15: In the defmethod, change "&rest initargs" to "&key" for better style,
since this method doesn't use or define any initargs, it should have an
empty set of &key parameters.  Also this method should be a :before method;
not a :after method, because we want to initialize the slots ourselves,
not let the primary method initialize them from initforms then reinitialize
them ourselves.  I think 1-44 and 1-47 should be modified to reflect this
valid use of :before methods for the two update- functions; they differ
in this respect from initialize-instance and reinitialize-instance.

2-17: The method signatures imply that only standard classes have names,
but I believe the intent was that all classes have names.  Certainly
built-in and structure classes do have names.

2-21 3rd paragraph: Someone complained that "The slot-name argument is
a symbol that can be used as a Common Lisp variable name." was ambiguous.
What we mean is that the symbol is syntactically valid for use as a
variable name, what we don't mean is that referencing a variable with
this name will access the slot.  This should be rephrased if possible.

2-33 last paragraph: The value returned by define-method-combination
should be the method combination meta object (now that we have them),
not the name.

2-37 2nd paragraph: I don't understand what this paragraph is doing
here.  Keyword options to what?  Did this paragraph drift in from
somewhere earlier in the define-method-combination section perhaps?

2-43: There is documentation for slot descriptor objects now too.
Since only chapter 3 describes those, I don't know whether slot
documentation should be documented in the normal way, or just
mentioned as a remark.  I think I prefer the former.

2-45 4th paragraph: Because of the way rule 4 for lambda-list
congruence is defined, I think this has to speak not of the old
and new lambda-lists for the generic function being congruent,
but of the new lambda-list for the generic function being congruent
with the lambda-lists of all existing methods.  If an implementation
can sometimes optimize this into a comparison with the old lambda
list for the generic function, that's merely an optimization.

2-55 2nd paragraph: I don't think the system supplied primary
method for initialize-instance checks the validity of the arguments,
since chapter 1 says make-instance takes care of that.  Unlike
reinitialize-instance, initialize-instance is not meant to be
called by the user.

2-55 Remarks field: This is not really accurate, as the generic
functions for which methods can be defined varies.  Chapter 1
describes this better, maybe the description should not be
repeated here.  It would be useful to have a remark that the programmer
is intended to define :after methods for initialize-instance.

2-58: Formatting of method signatures is particularly ugly here.
How about right-justifying "[Primary Method]" throughout this chapter?

2-74,5,6: Are you sure slot-boundp, slot-exists-p, and slot-makunbound
are generic?  slot-value isn't.  I guess Gregor has final say on this point.

2-85: Same comments as for 2-15.

2-90 first remarks paragraph: same comment as for 2-45.

2-92: with-slots should cross-reference with-accessors

∂19-May-88  1613	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I want to present one more alternative to the initargs checking
problem. This alternative was the result of a couple of hours'
discussion with Guy Steele tuesday night. There are two parts to
it. One is the real technical proposal, and the remainder is the
packaging for chapter 1.

We could introduce a new generic function called valid-keywords, which
takes an object; if it is something with keywords (like a generic
function, a method, or a function), valid-keywords returns two values: a
list of the explicitly named keywords and a boolean which states whether
&allow-other-keys had been specified in the definition.

Then we could write make-instance like this:

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
         (methods 
           (union
	     (compute-applicable-methods #'allocate-instance `(,class))
	     (union
	       (compute-applicable-methods #'initialize-instance `(,proto nil))
	       (compute-applicable-methods #'shared-initialize `(,proto))))))
	(unless
	 (subsetp
	  (let ((keys '()))
	       (do ((plist initargs (cddr plist)))
		   ((null plist) keys)
		   (push (car plist) keys)))
	  (union 
	    (class-slot-initargs class)
	    (reduce #'union (mapcar #'valid-keywords methods))))
	(error ...)))
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

Or something like this: the details of the code are not important
for chapters 1 and 2.

This is not a very simple piece of code to present in chapter 1. So
the proposal requires a sample of how to explain this:

\beginsubSection{Definitions of Make-Instance and Initialize-Instance}

The generic function {\bf make-instance} behaves as if it were defined as
follows, except that certain optimizations are permitted:

\screen!

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  ...
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

(defmethod make-instance ((class-name symbol) &rest initargs)
  (apply #'make-instance (find-class class-name) initargs))

\endscreen!

The elided code in the definition of {\bf make-instance} checks the
supplied initialization arguments to determine whether an initialization
argument was supplied that neither filled a slot nor supplied an argument
to an applicable method. This check could be implemented using the generic
functions {\bf class-prototype}, {\bf compute-applicable-methods}, {\bf
valid-keywords}, and {\bf class-slot-initargs}. See Chapter~3 for a
description of this initialization argument check.

The generic function {\bf initialize-instance} behaves as if it were
defined as follows, except that certain optimizations are permitted:

\screen!

(defmethod initialize-instance ((class standard-class) &rest initargs)
  (apply #'shared-initialize instance t initargs)))
 
\endscreen!

These procedures can be customized at either the Programmer Interface level,
the meta-object level, or both.  

Customizing at the Programmer Interface level includes using the {\bf
:initform}, {\bf :initarg}, and {\bf :default-initargs} options to
{\bf defclass}, as well as defining methods for {\bf make-instance}
and {\bf initialize-instance}.  It is also possible to define
methods for {\bf shared-initialize}, which would be invoked by the
generic functions {\bf reinitialize-instance}, {\bf
update-instance-for-redefined-class}, {\bf
update-instance-for-different-class}, and {\bf
initialize-instance}.  The meta-object level supports additional
customization by allowing methods to be defined on {\bf
make-instance}, {\bf default-initargs}, and {\bf
allocate-instance}.  Chapters~2 and~3 document each of these generic
functions and the system-supplied primary methods.

Implementations are permitted to make certain optimizations to {\bf
initialize-instance} and {\bf shared-initialize}.  The
description of {\bf shared-initialize} in Chapter~2 mentions the
possible optimizations.

Because of optimization, the check for valid initialization arguments
might not be implemented using the generic functions {\bf
class-prototype}, {\bf compute-applicable-methods}, {\bf valid-keywords},
and {\bf class-slot-initargs}. In addition, methods for the generic
function {\bf default-initargs}, and the system-supplied primary methods
for {\bf allocate-instance}, {\bf initialize-instance}, and {\bf
shared-initialize} may not be called on every call to {\bf make-instance}
or may not receive exactly the arguments that would be expected.

\endsubSection%{Definitions of MAKE-INSTANCE and Initialize-Instance}

∂20-May-88  1508	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 20 May 88  15:08:46 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 88 17:32-EDT
Date: Fri, 20 May 88 17:35 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880520213530.4.MLY@PERON.AI.MIT.EDU>

These comments come from someone who has been keeping an eye on the
cl-o-o-p mail, but hasn't been reading the specs regularly and closely.
I'm omitting remarks which would overlap those in
<380679.880518.MOON@AI.AI.MIT.EDU>

A general remark on all of the documents -- as a non-American and as
something of a pedant I feel my blood-pressure rising every time I
encounter ``congruent with'' or ``different than'' in the documents (as
opposed to ``congruent to'' and ``different from'' respectively.)  Is
this really Standard American English?

Another general remark is that Chapter 1 and Chapter 2 do not stand very
well apart from Chapter 3 -- there are too many functions mentioned in
passing which are never defined in any further fashion (or even
mentioned again!)  This certainly makes for rather hard reading and
comprehension.




1-22 2nd PP in `Intro to methods':  The first and second sentences
seem to be too directly contradictory.  I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.''

1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.''  Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs?  If
so, this should be made a lot clearer.

1-31 2nd PP.  ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.''  The uppercase text seems redundant.

1-31 5th PP.  I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...''

1-32 <foo>

1-33 Penultimate PP.  I am probably just plain confused on this point,
but is it possible that ``and instances of the classes standard-method,
...''  should read just ``the classes standard-method, ...''?  The
reference to standard-method in the following bulleted PP reinforces my
probably-mistaken belief.

1-39 3rd PP.  I question the use of the word ``captured'' (which occurs
in other places in both Chapters 1 and 2.)  ``Inherited'' seems more
straight-forward to me.  This is probably just a personal preference.

1-39 Table.  The last line would seem to imply that the defaulted
initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
(a 1 b 2).  Is this the intent?  It seems to unnecessarily constrain the
behaviour of default-initargs methods.

1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated.  Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods.  Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.

     At this point I suppose I might as well express my misgivings about
the name `shared-initialize' -- it seems to imply to me something to do
with `shared' (ie class-allocated) slots or something like that.  For
what it's worth, I'll state that the names `initialize-slots,'
`basic-initialize' and even `common-initialize' (or even
`initialize'!) appeal to me more than `shared-initialize.'

1-39 Last PP.  I would write ``The second argument to shared-initialize
may be one of the following:''

1-40 First (bulleted) PP.  What if the instance doesn't have a slot with
named by one of the elements of the list?  Is it ``an error?''  Is
slot-missing called?

1-40 4th bulleted PP.  It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.''  or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg.  I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.

1-41 `Definitions of make-instance and initialize-instance'
I think that it would make the manual a lot easier to read if similar
sample definitions were provided for the other initializations methods
(reinitialize-instance, update-instance-for-xxx, ...)  I think that
moving this section of sample definitions forward in the manual (perhaps
before the `shared-initialize' section, perhaps even very early in
`Objection Creation and Initialization') would provide much better
understanding of what the various generic functions do.
     This would also somewhat alleviate my above-mentioned problems with
the unmotivated appearance of `shared-initialize.'
     When I started reading from `Object Creation and Initialization' I
encountered a whole slew of names of generic functions on which I would
define methods, but no real reason for why I should want to do so for
around 7 more pages.
     I personally find it much easier to be presented with an overall
framework of code and then later `fill in the blanks' by reading what
the purpose of the various functions are than to wade though pages of
passing references to lots of functions before discovering how they fit
together and how they are supposed to be useful.

1-41 Definition of make-instance.  Is nobody else bothered by the fact
that the use DEFAULT-INITARGS may be a consful operation in the presence
of :default-initargs?  It would be very easy for the evaluation of
DEFAULT-INITARGS to consume more storage (to construct a merged initargs
list) than that of ALLOCATE-INSTANCE does in creation of the instance
itself! 

     My first reaction to this is to suggest a definition like:
    (defmethod make-instance ((class standard-class) &rest initargs)
      (apply #'with-defaulted-initargs
             (lambda (&rest defaulted-initargs)
               ...initarg error-checking code...
               (let ((instance (apply #'allocate-instance
                                      class defaulted-initargs)))
                 (apply #'initialize-instance instance defaulted-initargs)
                 instance))
             class initargs))
[where any implementation worth its salt would provide some way to
declare the dynamic extent of the INITARGS argument and the
LAMBDA-expression.]
     Of course there are other ways to do this sort of thing.

     I don't believe that the permissible optimizations mentioned are
sufficient to stop me worrying about this point.

     So, has nobody else considered this issue, or does nobody else
consider it an issue?

1-41 Last PP.  What ``certain optimizations are permitted.''  Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize.  The Chapter 2
description of shared-initialize explains this -- there should be some
xref.

1-42 Last PP.  I found this hard to read.  Suggestion:
``As a result of various optimizations, not all of the functions and
methods involved in initialization need necessarily be called on every
call to {\bf make-instance} and, if called, they may not receive exactly
the arguments that one would expect based on the sample implementation
above.''
     The example of a permitted optimization is bogus, because
check-keyword-arguments is not a method, and so the user has no business
redefining it, and so user methods have no way of telling whether it has
already been called or not (since it is stated that it won't signal an
error.)
     My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document.  I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.

1-43 6th PP.  The aside ``This two-step process ...'' disrupts the
description of what the process is.  Is should be moved below, after the
sentence ``... and other user-defined actions.''

1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed.  For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
Secondly, I don't think much would be lost be replacing each occurrence
of the intrusively-long

  Initialization arguments are declared as valid by using the {\bf
  :initarg} option to {\bf defclass} or by defining methods for {\bf
  <method-name>} or for {\bf shared-initialize}.  See the section
  ``Declaring the Validity of Initialization Arguments'' for more information.

with simply:

  (See the section ``Declaring the Validity of Initialization Arguments''
  for more information.)

Here's a suggested rewrite (I'd find code easier to read than this
turgid techno-English any day...):
  There is a system-supplied primary method for {\bf
  update-instance-for-redefined-class} whose parameter specializer for
  its instance argument is the class {\bf standard-object}.   This
  method first checks the validity of initialization arguments and
  signals an error if an initialization argument is supplied that is not
  declared as valid.  (See the section ``Declaring the Validity of
  Initialization Arguments'' for more information.)  Then it calls the
  generic function {\bf shared-initialize} with arguments of the
  instance, a list of names of the newly added slots, and the
  initialization arguments it received.

The now-redundant second half of the descriptions of these methods (with
appear in the ``Customizing foo'' sections) could be replaced by just

  Methods for {\bf shared-initialize} may be defined to customize class
  redefinition.  See the section ``Shared-Initialize'' for more
  information.





Finally, just to be contentious (I'm not inviting replies):

* I'm still convinced (after two years (even after reading all the
archived mail on the subject)) that optionals should be defaulted in the
generic function rather than the methods.... Oh well.

* I think it is a real loss that there is no way of specifying an
`interface function' such as New Flavors has.  The mess with the stupid
optional arg for DOCUMENTATION methods in chapter 2 is an example of
this.

* I'm aware of the problems they entail -- however I still find it a
pity that there is no provision for `private' methods and slots.

* I find the omission of defclass :constructors to be a significant
loss, based on past experience with implementing this sort of thing.

* I rely upon and heavily use New Flavors defun-in-method.  I don't see
how I could get equivalent performance via the use of WITH-SLOTS (since
I don't believe (the equivalent of) usage of a mapping table will be done
outside of method bodies.)

* I think that the use of STANDARD method combination for the various
initialization methods is a mistake.  It is too easy (for a ready
example, see the mistake Moon pointed out in <380731.880518.MOON@AI.AI.MIT.EDU>
about 2-15) to bash the useful system-defined method.  It is not at all
clear to me that it is ever useful to do this deliberately -- the only
thing it could do (which could not be done by defining an `auxiliary'
method on it or on shared-initialize) is inhibit error-checking.
  I hold that the `two-pass' method-combination used in Flavors for
initialize-instance is the right sort of thing: initialize-instance and
reinitialize-instance should use `progn-with-:after' method combination,
and update-instance-for-redefined-class and
update-instance-for-different-class should use `progn-with-:before'
method combination (I can't think of a use for :after methods on these
gf's.)
  Besides, use of non-STANDARD method-combination would actually show
readers that all this method-combination hair is actually good for
anything!

* I find the `evalness' of define-method-combination very disturbing.
It seems to me that a full lisp compiler or evaluator will need to be
present in any world into are loaded methods on generic functions which
use user-defined method-combination.  I would -very- much like to be
convinced that this isn't the case.

* IWBNI GET and (SETF GET) were made generic, though I suppose the same
sort of argument could be made for dozens of other CLtL functions.

∂20-May-88  1703	Common-Lisp-Object-System-mailer 	Comments on new draft chapter 1 (dated May 13 20:53)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88  17:03:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408054; 20 May 88 20:02:25 EDT
Date: Fri, 20 May 88 20:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on new draft chapter 1 (dated May 13 20:53)
To: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880520213530.4.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521000213.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 20 May 88 17:35 EDT
    From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>

Comments on a subset of your comments, not to imply that the remainder
should be ignored.  In general I agree with them.

    1-25 To this reader, the statement in the 4th enumerated PP that ``The
    checking of the validity of keyword names is done in the generic
    function, not in each method'' seems inconsistent with the second PP on
    1-26 ``If a method is passed a keyword argument is does not accept, an
    error is signaled.''  Is the indent to draw some distinction between &key
    args from DEFGENERIC and those which come from random DEFMETHODs?  If
    so, this should be made a lot clearer.

I missed this one in my recent review of the document.
I believe the word "method" in the 2nd pp on 1-26 is a typo and should
be "generic function."  Clearer would be "If a generic function is passed
a keyword argument that no applicable method accepts, an error is signaled."
Also, for consistency with the last paragraph on CLtL p.62, it should be
"an error should be signaled" rather than "an error is signaled."  Not
that I am a fan of implementations that allow you to turn off error checking.

    1-32 <foo>

I don't follow.

    1-33 Penultimate PP.  I am probably just plain confused on this point,
    but is it possible that ``and instances of the classes standard-method,
    ...''  should read just ``the classes standard-method, ...''?  The
    reference to standard-method in the following bulleted PP reinforces my
    probably-mistaken belief.

No, the text is correct as it stands.  Everything involving meta objects is
inherently confusing because it's difficult to keep the two levels straight.

    1-39 3rd PP.  I question the use of the word ``captured'' (which occurs
    in other places in both Chapters 1 and 2.)  ``Inherited'' seems more
    straight-forward to me.  This is probably just a personal preference.

"Captured" refers to lexical capturing, not class inheritance.  I'm not
sure it's necessary to repeat "captured" periodically; we could just leave
it to the explanation on 1-10 and again on 1-35.

    1-39 Table.  The last line would seem to imply that the defaulted
    initlist must always be '(a 1 a 2 b 2), ruling out the `optimization'
    (a 1 b 2).  Is this the intent?  It seems to unnecessarily constrain the
    behaviour of default-initargs methods.

"a 2" was not put in by defaulting, it was supplied explicitly by the caller.
Given that, I don't think we want to change the table.

    1-39 The section `Shared-Initialize' The introduction of this section at
    this point seems very unmotivated.  Nowhere above (except by implication
    of the `--'-bulleted PPs on 1-37) is it made clear that
    shared-initialize is an `underlying' method called by all the various
    (re)initialization methods.  Some small preamble at the beginning of
    this section would make a first-time reading of the the spec somewhat
    easier.

The spec is deliberately made difficult to read to discourage people from
making implementations without reading it slowly and carefully :-)

	 At this point I suppose I might as well express my misgivings about
    the name `shared-initialize' -- it seems to imply to me something to do
    with `shared' (ie class-allocated) slots or something like that.  For
    what it's worth, I'll state that the names `initialize-slots,'
    `basic-initialize' and even `common-initialize' (or even
    `initialize'!) appeal to me more than `shared-initialize.'

The false connotation of shared slots is the same comment I had.  However,
all four of your suggested alternatives have problems, and we spent so much
time trying to find a better name that I think we should go with the one
we have for this round of the document, and let X3J13 instruct us to change
it if they so desire.

    1-40 First (bulleted) PP.  What if the instance doesn't have a slot with
    named by one of the elements of the list?  Is it ``an error?''  Is
    slot-missing called?

You're right, we need to specify this.  Let's make it "the results are
unspecified."

    1-41 Definition of make-instance.  Is nobody else bothered by the fact
    that the use DEFAULT-INITARGS may be a consful operation in the presence
    of :default-initargs?  It would be very easy for the evaluation of
    DEFAULT-INITARGS to consume more storage (to construct a merged initargs
    list) than that of ALLOCATE-INSTANCE does in creation of the instance
    itself! 

Of course.  But the spec defines the semantics of the language, not how
to do semantics-preserving implementation-dependent optimizations.  I
don't think complicating the specification to make it slightly more
obvious how to optimizations is a good tradeoff.  Also, with reasonable
garbage collectors, which are starting to emerge even on traditional
hardware, consing is not such a burden.

    Finally, just to be contentious (I'm not inviting replies):

Yes, CLOS definitely has that design-by-committee aroma.

    * I find the `evalness' of define-method-combination very disturbing.
    It seems to me that a full lisp compiler or evaluator will need to be
    present in any world into are loaded methods on generic functions which
    use user-defined method-combination.  I would -very- much like to be
    convinced that this isn't the case.

I don't understand your point.  How is define-method-combination different
from defmacro in this respect?  Perhaps you've been misled by the way the
spec describes everything as if it was interpreted into thinking that it
cannot be compiled?

∂20-May-88  2010	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88  20:09:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191392; Fri 20-May-88 23:08:50 EDT
Date: Fri, 20 May 88 23:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments   
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 19 May 88 19:13 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880521030857.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 19 May 88  1613 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I want to present one more alternative to the initargs checking
    problem.

[Getting rid of check-initargs & successors, writing the code inline,
and putting it in chapter 3.]

This sounds good to me, with a couple modifications suggested below.
Let's go with it.

    We could introduce a new generic function called valid-keywords, which
    takes an object; if it is something with keywords (like a generic
    function, a method, or a function), valid-keywords returns two values: a
    list of the explicitly named keywords and a boolean which states whether
    &allow-other-keys had been specified in the definition.

function-keywords would be a better name.  Otherwise okay.
I have no quarrel with the dual return values.
[Yes, I know (subtypep 'method 'function) => nil t.  Nonetheless,
in this context the method is used in a functionesque way.]

I assume method-applicable-keywords, p.27 of the most recent draft
of ch.3 that I've seen (the one handed out at X3J13 in March), would
go away.

    Then we could write make-instance like this:

    (defmethod make-instance ((class standard-class) &rest initargs)
      (setq initargs (default-initargs class initargs))
      (let* ((proto (class-prototype class))
	     (methods 
	       (union
		 (compute-applicable-methods #'allocate-instance `(,class))
		 (union
		   (compute-applicable-methods #'initialize-instance `(,proto nil))
		   (compute-applicable-methods #'shared-initialize `(,proto))))))

I think you want append rather than union, since there won't be any
methods in common between distinct generic functions.  Also the args for
initialize-instance and shared-initialize have accidentally gotten
interchanged.

	    (unless
	     (subsetp
	      (let ((keys '()))
		   (do ((plist initargs (cddr plist)))
		       ((null plist) keys)
		       (push (car plist) keys)))
	      (union 
		(class-slot-initargs class)
		(reduce #'union (mapcar #'valid-keywords methods))))
	    (error ...)))
      (let ((instance (apply #'allocate-instance class initargs)))
	(apply #'initialize-instance instance initargs)
	instance))

∂20-May-88  2206	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I think Moon's suggestion for the name FUNCTION-KEYWORD is acceptable.
Here is the corrected code (Having Moon around to read code is
almost as good as having a computer. In fact, it's better because
sometimes he cracks a joke.):

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
         (methods 
           (append
	     (compute-applicable-methods #'allocate-instance `(,class))
	     (compute-applicable-methods #'initialize-instance `(,proto))
	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
	(unless
	  (subsetp
	    (let ((keys '()))
	      (do ((plist initargs (cddr plist)))
		  ((null plist) keys)
		(push (car plist) keys)))
	    (union 
	      (class-slot-initargs class)
	      (reduce #'union (mapcar #'function-keywords methods))))
	  (error ...)))
  (let ((instance (apply #'allocate-instance class initargs)))
    (apply #'initialize-instance instance initargs)
    instance))

∂21-May-88  0017	Common-Lisp-Object-System-mailer 	Mlynarik's comments  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


First I'll address the general grammatical comments. As far as I can tell
by reading the OED, ``congruent with'' is standard British English.  Using
Webster's Second Unabridged - the most prescriptive American English
dictionary - I find ``congruent with'' used in general contexts and in
most mathematical contexts.  My perusal of math texts seems to indicate
``congruent to'' is acceptable when discussing number theory. I cannot
find explicit grammatical justification for ``congruent to'' in any
context. Because we are not talking about number theory, I don't believe
any changes are necessary.

It is currently correct to use the following rules for ``different'':  The
phrase ``different from'' is used when introducing a phrase while
``different than'' is used when introducing a clause. My references claim
``different from'' and ``different than'' have both appeared for the
last 300 years. British usage admits ``different to.''

Note there is no use of ``different than'' (or ``different from'')
in chapter 1.

To comment further on the grammar in chapters 1 and 2. Linda and I are
both relatively careful writers in terms of grammar, and I can assure you
that we have not dashed off this piece.  Furthermore, we have engaged copy
editors to proofread major drafts of these chapters before they are sent
out. The style of writing might be academic, but I believe it corresponds
to acceptable Amercian English in all cases, and even the editors of the
OED now accept American usage as standard.

The remainder of this message is a response to Richard's comments. I have left
out specific comments to which Moon responded with remarks with which I
agree.

Richard writes:

``1-22 2nd PP in `Intro to methods':  The first and second sentences
seem to be too directly contradictory.  I would change the first to
``A method object is not NECESSARILY a function an IN GENERAL cannot be
invoked as a function.'' ''

The sentences in question are:

``A method object is not a function and cannot be invoked as a function.  An
implementation may extend the \OS\ so that method objects are functions.''

The reason it is stated this way is that no one writing portable code can
take them to be functions, but we do not require them to not be functions
in all implementations.  If we wrote it your way then someone could
legitimately understand that within a single implementation a particular
method object may or may not be a function. 

The style we use consistently throughout is to state a constraint
and then allow extensions.

Richard writes:

``1-25 To this reader, the statement in the 4th enumerated PP that ``The
checking of the validity of keyword names is done in the generic
function, not in each method'' seems inconsistent with the second PP on
1-26 ``If a method is passed a keyword argument is does not accept, an
error is signaled.''  Is the indent to draw some distinction between &key
args from DEFGENERIC and those which come from random DEFMETHODs?  If
so, this should be made a lot clearer.''

Moon's remark is correct and the passage has been repaired.

Richard writes:

``1-31 2nd PP.  ``to the :method-combination option to defgeneric or TO
THE :METHOD-COMBINATION OPTION TO any of the other forms that specify
generic function options.''  The uppercase text seems redundant.''

It is redundant and intentionally so: You cannot possibly misread
the current version. A misreading would be

``To specify that a generic function is to use one of these method
combination types, the name of the method combination type is given as the
argument ... to any of the other forms that specify generic function
options.''

Richard writes:

``1-31 5th PP.  I would replace this with ``The simple build-in method
combination types COULD HAVE BEEN defined...'' ''

``Could have been'' but weren't? Your rewrite talks about an implementation
choice that may or may not be relevant, whereas the current language
discusses semantics.

Richard writes:

``1-32 <foo>''

I agree with Richard on the weirdness of this description, but
I could not (and still cannot) think of a more precise approach to
describing this. I have spent weeks on the bulleted item over the
last 2 years.

Richard writes:

``1-39 Last PP.  I would write ``The second argument to shared-initialize
may be one of the following:''  ''

Right.

Richard writes:

``1-39 The section `Shared-Initialize' The introduction of this section at
this point seems very unmotivated.  Nowhere above (except by implication
of the `--'-bulleted PPs on 1-37) is it made clear that
shared-initialize is an `underlying' method called by all the various
(re)initialization methods.  Some small preamble at the beginning of
this section would make a first-time reading of the the spec somewhat
easier.''

Right. I added such an introduction to shared-initialize early
in the section.

Richard writes:

``1-40 4th bulleted PP.  It should be noted that ``This happens regardless
of whether or not the slot is specified by the second argument.''  or
something along those lines -- make it completely clear that this first
step in initialization depends only on the &key initarg, not on the
slot-name-specification arg.  I'd also like to see a similar comment in
the Chapter 2 doc for shared-initialize.''

Right.

Richard writes:

``1-41 Last PP.  What ``certain optimizations are permitted.''  Nothing is
mentioned here or in the Chapter 2 description of initialize-instance to
explain what these might be, any how they might affect writers of
methods on initialize-instance or shared-initialize.  The Chapter 2
description of shared-initialize explains this -- there should be some
xref.''

I thought it already cross-references to shared-initialize.

Richard writes:

``1-42 Last PP.  I found this hard to read.  Suggestion....''

This paragraph has been rewritten based on the newthink on the
check-initargs problem.

Richard writes:

``     My feeling is that the vagueness in this section is very
unpleasant, and quite inconsistent with the general precision in the
rest of the document.  I have some ideas on how to improve this, if
there is any interest in re-opening this issue and in listening to them.''

Yes, I would like to hear your ideas.

Richard writes:

``1-43 6th PP.  The aside ``This two-step process ...'' disrupts the
description of what the process is.  Is should be moved below, after the
sentence ``... and other user-defined actions.'' ''

This paragraph is now different enough that this comment isn't as valid.
In particular, other circumstances have been added in which the process
can start up, and the discussion of when it can happen is the current
focus of the paragraph.

Richard writes:

``1-44 6th PP, 1-46 last PP, 1-48 4th PP.
I find these incredibly disjointed.  For starters, only half of the
contract of the ``system-supplied primary method'' is mentioned -- the
other half is to be found two paragraphs down -- in a different section!
....''

Good idea. I've so modified the sections.

			-rpg-

∂21-May-88  0651	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  06:51:05 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:51:30 PDT
Received: from bhopal.lucid.com by edsel id AA20037g; Sat, 21 May 88 06:40:47 PDT
Received: by bhopal id AA08392g; Sat, 21 May 88 06:44:29 PDT
Date: Sat, 21 May 88 06:44:29 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211344.AA08392@bhopal.lucid.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Comments on current state of Initialization.

Why should there still  be three initialization protocls: "shared-initialize",
"initialize-instance",  and "reinitialize-instance" (sp?).  

Why not just "initialize-instance" with a keyword argument for whether or 
not it is a first-time initialization?  In each case, the specialization
needed is over the instance, and not over the slots-for-initforms argument,
or the initargs argument, or any other arugment.  And so _most_ of the 
processing will be the same regardless of whether the caller is make-instance
or one of the update-instance-for-<munged>-class functions (i.e., whether 
initializing afresh or whether re-initializing).  In fact, for many classes 
I would guess that the particular list given as the 'slots-for-initforms' 
argument would adequately cover any necessary distinctions between fresh 
allocation and "update-instance-for-<munged>-class".  Direct user calls, if
any, could pass this keyword argument, rather than decide between two 
differently named functions.

I presume that the main primary method is the one whose chief purpose is to
set slots, first from the initargs and then from the initforms, and that this
wouldn't need to be modified by the user.  [In fact, letting the user change
this primary method is probably a mistake.]  Again, I would guess that most
user :after methods wouln't be concerned with the distinction between
"fixing up" the initialization of a fresh instance, and that of "fixing up"
the re-setting of slots on an "old" instance; in each case, the more 
important information is in the 'slots-for-initforms' argument.


In short, what I fail to see is any justification for hairing up the
protocol to inject a generic function that seems to have no particular
user benefit: reinitialize-instance.  Looking over back mail, I find
this one comment from Danny:

    Date: 8 Apr 88 15:37 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    Subject: Re: (re)initialization revisited 
    In-Reply-To: kempf@Sun.COM's message of Thu, 07 Apr 88 12:13:45 -0700
    To: kempf@Sun.COM
    Cc: common-lisp-object-system@SAIL.STANFORD.EDU

    Jim proposes removing some functions in the spec.  I sympathize with this 
    as a general goal.  But in this case I think it is misguided.  There are 
    really four concepts
    1) initializate (make a brand new instance have the right state)
    2) reinitialize (make an old instance have a "standard" starting state)
    3) class-changed (make a change from one form of current instance to another)
    4) update-instance-structure (make an appropriate current instance from an
    outdated instance.

    Because there are four concepts, there must be four entries so that users 
    can change what is done for each.  Collapsing concepts into a commonly 
    named fn just causes confusion.

    . . . 

    Reinititializing must potentially take into account old values on slots.
    Initialization never has to.  We introduced the general concept because we
    had two examples in CLOS itself that require it: instances of 
    standard-class, and instances of standard-generic-function.  Both must 
    take into account previous state of the objects to be changed.

But still, this is not justification for imposing a complexity that
will almost never be used by the end user, and for which there is an
adequate alternative: keyword argument to initialize-instance.  Note
that there is no need to split off re-initialization due to a difference
in the ways in which it might be specialized.


-- JonL --

∂21-May-88  1602	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88  16:02:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191452; Sat 21-May-88 19:01:56 EDT
Date: Sat, 21 May 88 19:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richard MlYNarIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521191828.5.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 15:18 EDT
    From: Richard MlynBaOrik <Mly@AI.AI.MIT.EDU>

    [common-lisp-object-system@SAIL.STANFORD.EDU removed]

[Added back since I thought it was useful for the whole list to see
the reply.  I don't expect I'm embarrassing you.]

	Date: Fri, 20 May 88 20:02 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	    * I find the `evalness' of define-method-combination very disturbing.
	    It seems to me that a full lisp compiler or evaluator will need to be
	    present in any world into are loaded methods on generic functions which
	    use user-defined method-combination.  I would -very- much like to be
	    convinced that this isn't the case.

	I don't understand your point.  How is define-method-combination different
	from defmacro in this respect?  Perhaps you've been misled by the way the
	spec describes everything as if it was interpreted into thinking that it
	cannot be compiled?

    I'm wondering how add-method works.

    If one does a random add-method to a generic function (say by loading a
    file containing a defmethod form) then whenever the combined
    (`effective') method is created (at instance instantiation time or
    whenever) something has got to look at the lisp code produced by the
    `macroexpansion' of a define-method-combination form.  This
    macroexpasion can't be performed any earlier, because it depends on the
    applicable methods.

That's quite a reasonable concern to have, however we've thought of it.

The compiler can anticipate what add-method calls are going to be
produced by forms the compiler has seen, such as defmethod forms.  The
code resulting from method-combination can be predicted at compile time
and compiled then, with a simple mechanism to make sure at load time
that that pregenerated code gets used.  This is how it works in Flavors,
so that's an existence proof.

Of course if a program calls add-method at run time in a way the compiler
can't anticipate, such techniques can't win.  But I'd say that kind of
program, which changes its structure at run time, should not be surprised
to depend on having a compiler at run time.

    As I see it, either the lisp evaluator is used whenever the combined
    method is called or else the lisp code produced by
    define-method-combination has to be turned into something executable by
    `the machine.'

It's also true that an evaluator different from the Lisp evaluator can
be used.  For example, the form returned by the method combination
function can be recognized as an instance of a pattern and the effective
method can be a closure of a preexisting function that knows how to
"evaluate" such forms; the enclosed variables typically have methods or
lists of methods as their values.  The preexisting functions can even be
generated automatically when the system is compiled, from declarative
specifications (arrange for x type of method combination to work with n
applicable methods in role z).  Some types of method combination work
this way in Flavors in 7.2 [oh, I see you know that], and I'm told PCL
also works this way.  I assume that CLOS can work this way, too, using
the world's simplest pattern matcher to recognize forms returned by
method combination functions.

∂21-May-88  1605	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 21 May 88  16:04:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191453; Sat 21-May-88 19:04:12 EDT
Date: Sat, 21 May 88 19:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805211344.AA08392@bhopal.lucid.com>
Message-ID: <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 06:44:29 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>

    Why should there still  be three initialization protocls: "shared-initialize",
    "initialize-instance",  and "reinitialize-instance"?

    [Summary: replace reinitialize-instance with a keyword argument to
    initialize-instance --Moon]

Two reasons come immediately to mind: shared-initialize is also used when a
class is redefined or change-class is called; reinitialize-instance is to be
called directly by the user, but initialize-instance cannot be (review how
the keyword arguments get validated).

∂21-May-88  1923	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 21 May 88  19:23:33 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 88 22:24-EDT
Date: Sat, 21 May 88 22:27 EDT
From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Subject: define-method-combination
To: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880521230158.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880522022721.6.MLY@PERON.AI.MIT.EDU>

Before I launch into the usual tirade, I'd like to make a suggestion
which might have some hope of being considered:

define-method-combination should accept an option
  (:generic-function <symbol>)
and bind <symbol> to the relevant generic function.
This has much the same flavour as the existing :arguments option.
I think that this is a nicer solution than binding
a magic variable named `generic-function'.

======================================================================

I only partially believe what Moon says about define-method-combination.

On the whole, I find his arguments unfortunate sorts of thing to have to
claim, especially when there are another ways of declaring method
combination this which avoids this sort of problem.  (By constructing
closures rather than s-expressions.)

I do believe his arguments as applied to system-predefined
method-combination -- after all, and as he says, we have Flavors as an
existence proof.

On the other hand, as long as I've been using lisp machines (up to this
very day) I've encountered combined methods which weren't caught at
compile-time.  So I suppose we should say that we would have Flavors as
existence proof in principle...


I very much doubt that a user will in fact be able to declare enough to
the system to generate the same quality of code as the specially-
recognised predefined system method combination types -- let
alone that s/he would be able to declare this is any portable way!

I realize that CLOS is only specifying semantics, but why make things
harder than they need be, so hard they they need a Sufficiently Smart
Compiler Sufficiently Useful Magic-Unspecified-Declarations/
Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
(For years there has been talk about sufficiently smart compilers taking
all of my troubles away, but I've yet to see evidence of such things.)

My overall fear is that this sort of approach will create two classes of
programs -- those which use the system's predefined method combination
types and standard method definition (such as defmethod with
:method-class standard-method) and those which use anything else.  The
first class of programs can expect a much higher level of support than
the latter, because the compiler has been taught special tricks.  I like
to think that one of the aims of CLOS in general (though Chapter 3-style
specifications) is to expose as much of the underlying works as is
necessary to allow non-`standard' classes/method-combination/etc to be
able to expect a level of support which is at least of the same order of
magnitude as that provided by the system.  This certainly does not seem
to be the case with user-defined method-combination types.

(I know there are limits to this argument -- for example I doubt that J.
Random Generic-function Metaclass could expect the same performance as
implementation-tuned standard-generic-function.)

However, if user-defined method combination is to be a toy which works
1/1000th as well as system-defined method combination (because it has to
call out to the evaluator or otherwise do a bunch of unnecessary hair at
run time or require the presence of a full lisp compiler) then why
bother specifying it at all?  I'm sure most people will be happy with a
few standard method combination types -- why clutter up the world and
raise people's expectations with something which can't be guaranteed to
work very well?   Especially, why clutter the world so much the EVAL
becomes required (when nothing else in CLtL except for the section on
the evaluator seems to require such a horrible thing)?



BTW I've looked at the pattern-matchers (by no means ``the world's
simplest'' -- PCL's uses a real code-walker) in both PCL and Flavors and
still doubt that they can do enough before they become full lisp
compilers.  (When Flavor's pattern-matcher punts, it ends up calling
compile.)

I don't believe Moon's argument that something less than a full lisp
evaluator will do to interpret user-defined effective methods -- it is
trivial to define a method combination type (and not even a particularly
contrived one) which will defeat this.



I guess Scheme has gone badly to my brain -- the mere hint of run-time
evaluation/compilation makes me feel ill (the symptoms are flames coming
from the mouth.)  There is another reason, though:  I have recently had
very bad experiences with a very large piece of software which suffered
and suffered (and made me suffer) because of the way it called out to
the evaluator. 



Anyway, this whole issue was originally filed under the
``Just to be contentious'' label -- I didn't expect and still do not
expect to convince anybody.

I am not going to continue to flame about this.

∂23-May-88  0644	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 May 88  06:44:34 PDT
Received: by ti.com id AA26663; Mon, 23 May 88 08:43:54 CDT
Received: from Jenner by tilde id AA28453; Mon, 23 May 88 08:31:19 CDT
Message-Id: <2789386229-306446@Jenner>
Date: Mon, 23 May 88  08:30:29 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: check-keyword-arguments   
In-Reply-To: Msg of 20 May 88  2206 PDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>

     Date: 20 May 88  2206 PDT
     From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
     Subject: check-keyword-arguments   
     
     
     (defmethod make-instance ((class standard-class) &rest initargs)
       (setq initargs (default-initargs class initargs))
       (let* ((proto (class-prototype class))
              (methods 
                (append
     	     (compute-applicable-methods #'allocate-instance `(,class))
     	     (compute-applicable-methods #'initialize-instance `(,proto))
     	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
     	(unless
     	  (subsetp
     	    (let ((keys '()))
     	      (do ((plist initargs (cddr plist)))
     		  ((null plist) keys)
     		(push (car plist) keys)))
     	    (union 
     	      (class-slot-initargs class)
     	      (reduce #'union (mapcar #'function-keywords methods))))
     	  (error ...)))
       (let ((instance (apply #'allocate-instance class initargs)))
         (apply #'initialize-instance instance initargs)
         instance))

I agree, expect that the second value returned by function-keywords needs
to be looked at. Something like this would work (I think):

(defmethod make-instance ((class standard-class) &rest initargs)
  (setq initargs (default-initargs class initargs))
  (let* ((proto (class-prototype class))
	 (methods 
	   (append
     	     (compute-applicable-methods #'allocate-instance `(,class))
     	     (compute-applicable-methods #'initialize-instance `(,proto))
     	     (compute-applicable-methods #'shared-initialize `(,proto nil)))))
    (unless
      (block check-keys
	(let ((valid-keys (class-slot-initargs class)))
	  (dolist (method methods)
	    (multiple-value-bind (keys allow-other-keys-p)
		(function-keywords method)
	      (if  allow-other-keys-p
		   (return-from check-keys t)
		   (setf valid-keys (union keys valid-keys)))))
	  (subsetp
	    (let ((keys '()))
	      (do ((plist initargs (cddr plist)))
		  ((null plist) keys)
		(push (car plist) keys)))
	    valid-keys)))
     	  (error ...)))
      (let ((instance (apply #'allocate-instance class initargs)))
	(apply #'initialize-instance instance initargs)
	instance))

Patrick.

∂23-May-88  0842	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 May 88  08:42:19 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA04663; Mon, 23 May 88 08:41:00 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA15995; Mon, 23 May 88 08:38:27 PDT
Received: from localhost by suntana.sun.com (3.2/SMI-3.2)
	id AA04572; Mon, 23 May 88 08:33:04 PDT
Message-Id: <8805231533.AA04572@suntana.sun.com>
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: define-method-combination 
In-Reply-To: Your message of Sat, 21 May 88 22:27:00 -0400.
             <19880522022721.6.MLY@PERON.AI.MIT.EDU> 
Date: Mon, 23 May 88 08:33:01 -0700
From: kempf@Sun.COM


>On the other hand, as long as I've been using lisp machines (up to this
>very day) I've encountered combined methods which weren't caught at
>compile-time.  So I suppose we should say that we would have Flavors as
>existence proof in principle...

Unfortunately, I suspect that you may be right about this. However, I don't
necessarily believe that this makes user defined method combination types
useless. Certainly, for prototype or experimental code, where performance
is not as critical, they should be useful. And CLOS has been designed
with the needs of experimentalists in mind. There may even be some
applications which don't mind having a full evaluator or compiler around.
In fact, how many Lisp applications run today *without* a full evaluator
or compiler around (rhetorical question, very few I suspect).

>I realize that CLOS is only specifying semantics, but why make things
>harder than they need be, so hard they they need a Sufficiently Smart
>Compiler Sufficiently Useful Magic-Unspecified-Declarations/
>Sufficiently Powerful Magic-Unspecified-Pattern-Matching-Language/ etc?
>(For years there has been talk about sufficiently smart compilers taking
>all of my troubles away, but I've yet to see evidence of such things.)

When somebody manages to convince a funding agency like DARPA that 
research on advanced Lisp compilers is important, it will happen. 
Until then, forget it. Lots of people have plenty of ideas about 
how to make Lisp compilers Sufficiently Smart, unfortunately, maintenance
of existing compilers, addition of features (like multiprocessing) and
environmental support have taken precedence in the commercial field,
because that is what customers are asking for. The way things are 
currently going, we should be happy if a product quality CLOS is
available within a reasonable amount of time, and I'm not talking about
the technical side of implementing it.

>My overall fear is that this sort of approach will create two classes of
>programs -- those which use the system's predefined method combination
>types and standard method definition (such as defmethod with
>:method-class standard-method) and those which use anything else.  The
>first class of programs can expect a much higher level of support than
>the latter, because the compiler has been taught special tricks.  I like
>to think that one of the aims of CLOS in general (though Chapter 3-style
>specifications) is to expose as much of the underlying works as is
>necessary to allow non-`standard' classes/method-combination/etc to be
>able to expect a level of support which is at least of the same order of
>magnitude as that provided by the system.  This certainly does not seem
>to be the case with user-defined method-combination types.

This is a goal, however, there is a real question of how much the
underlying works can be exposed without constraining the implementation
so much that the standard system defined generic functions and method
combinations can't be compiled efficiently. Unless someone does an
existence proof, it is unlikely that we will really know, because a
paper specification might miss something important. After having tuned
up PCL, I know that the level of metaobject support in PCL can be implemented
very efficiently on stock hardware, however, the version of PCL I used
didn't have method combination, much less user defined method combination.
Of course, any attempt to add additional features invalidates the existence
proof.

>I guess Scheme has gone badly to my brain -- the mere hint of run-time
>evaluation/compilation makes me feel ill (the symptoms are flames coming

More importantly for commercial purposes, C++. That's the competition.
While it is unlikely that we will be able to get performance comparible
to C++ on the first round, given your Sufficiently Smart compiler, it
should be possible to approach it. Whether a Sufficiently Smart CLOS
compiler happens, however, is again a question of priorities. 


		jak

∂23-May-88  0948	Common-Lisp-Object-System-mailer 	Re: check-keyword-arguments    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  09:48:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 09:47:58 PDT
Date: 23 May 88 09:46 PDT
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: check-keyword-arguments   
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 20 May 88 22:06
 PDT
To: RPG@SAIL.Stanford.EDU
cc: common-lisp-object-system@SAIL.Stanford.EDU
Message-ID: <880523-094758-4593@Xerox>

I am happy to see this version of make-instance PROVIDED we put
compute-applicable-methods and function-keywords in chapter 2.   I think both
provide features which are useful to programmers working with CLOS as it stands
rather than with possibly extending the system.  compute-applicable-methods is
parallel to find-method, and function-keywords is similar to method-qualifiers,
both of which are in chapter 2.  I mildly prefer the name  method-keywords since
its argument is a method.I would also suggest find-applicable-methods to
parallel find-method. 
  

∂23-May-88  1047	Common-Lisp-Object-System-mailer 	More Check-Keyword-Arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I have no problems with compute-applicable-methods and function-keywords
being in chapter 2, except that we are on top of the two-week rule
and have to blast out to make it. Function-keywords is a good name because
it is a generic function, and some Common Lisps might extend it to CL functions.
I preferred valid-keywords because it did not talk about either functions or
methods.

			-rpg-

∂23-May-88  1055	Common-Lisp-Object-System-mailer 	define-method-combination 
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88  10:55:02 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191675; Mon 23-May-88 13:54:24 EDT
Date: Mon, 23 May 88 13:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: define-method-combination
To: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <19880522022721.6.MLY@PERON.AI.MIT.EDU>
Message-ID: <19880523175424.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 21 May 88 22:27 EDT
    From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>

    Before I launch into the usual tirade, I'd like to make a suggestion
    which might have some hope of being considered:

    define-method-combination should accept an option
      (:generic-function <symbol>)
    and bind <symbol> to the relevant generic function.
    This has much the same flavour as the existing :arguments option.
    I think that this is a nicer solution than binding
    a magic variable named `generic-function'.

I agree.  I think this just got overlooked when :arguments was added,
because before that there wasn't any agreed-upon syntax for saying
things like this.  Group: Is there still time to change this?

    ....
    On the other hand, as long as I've been using lisp machines (up to this
    very day) I've encountered combined methods which weren't caught at
    compile-time.

And as long as I've been using Lisp, I've encountered files that use a macro
that has been changed, but no one remembered to recompile the file, so the
caller of the macro was not updated.  Few people propose to remove macros
from Lisp for that reason.  I just don't think your argument is relevant.

    ....
    My overall fear is that this sort of approach will create two classes of
    programs -- those which use the system's predefined method combination
    types and standard method definition (such as defmethod with
    :method-class standard-method) and those which use anything else.  The
    first class of programs can expect a much higher level of support than
    the latter, because the compiler has been taught special tricks.  

I agree that that could happen, but I see no reason why it must.

								      I like
    to think that one of the aims of CLOS in general (though Chapter 3-style
    specifications) is to expose as much of the underlying works as is
    necessary to allow non-`standard' classes/method-combination/etc to be
    able to expect a level of support which is at least of the same order of
    magnitude as that provided by the system.  This certainly does not seem
    to be the case with user-defined method-combination types.

I agree with your first sentence, but don't see why you think
user-defined method-combination types are any different from anything
else.  Also, you've changed your argument.  First you said user-defined
method combination types require the existence of a compiler at load
time (and implicitly you assumed that all Lisps are like most of today's
(but not the 1950's!) Lisps, in that if you have a compiler at load
time, you cannot get rid of it at run time).  Now you're saying that
user-defined method combination won't compile as efficiently as standard
method combination, an entirely different argument.  I think your new
argument is analogous to saying that it's better to use DO than LOOP,
not because you like the syntax better, but because DO as a built-in
macro is likely to compile more efficient code than LOOP, as a
user-defined macro.  That's even true to some extent with some
compilers, but few people change their whole programming style on the
basis of that kind of consideration, and in all the arguments against
LOOP I've heard over the years, I don't recall ever hearing that one.
I really believe that method combination is just like a macro.

    However, if user-defined method combination is to be a toy which works
    1/1000th as well as system-defined method combination (because it has to
    call out to the evaluator or otherwise do a bunch of unnecessary hair at
    run time or require the presence of a full lisp compiler)

Please, please, please do not be confused by the interpreter-oriented
presentation, any more than you would be confused by a Lisp textbook which
explained the language in interpretive terms and only introduced the compiler
in a late chapter.  Semantics are easier to explain interpretively, but no
one proposes calling out to the evaluator in any real implementation.

    then why
    bother specifying it at all?  I'm sure most people will be happy with a
    few standard method combination types -- why clutter up the world and
    raise people's expectations with something which can't be guaranteed to
    work very well?

Change "method combination type" to "macro" and read your argument again.
Of course, there are people in the Scheme community who believe that argument.
I think Common Lisp is way past aspiring to that level of purity, though.

    I don't believe Moon's argument that something less than a full lisp
    evaluator will do to interpret user-defined effective methods -- it is
    trivial to define a method combination type (and not even a particularly
    contrived one) which will defeat this.

Of course.  It's also trivial to write a program that cannot be compiled.
In practice, people who care about the issue you're concerned with don't
do those things.

∂23-May-88  1105	Common-Lisp-Object-System-mailer 	Re: define-method-combination  
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 23 May 88  11:05:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191680; Mon 23-May-88 14:05:18 EDT
Date: Mon, 23 May 88 14:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: define-method-combination 
To: kempf@Sun.COM
cc: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>, common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8805231533.AA04572@suntana.sun.com>
Message-ID: <19880523180527.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 23 May 88 08:33:01 -0700
    From: kempf@Sun.COM

    More importantly for commercial purposes, C++. That's the competition.
    While it is unlikely that we will be able to get performance comparible
    to C++ on the first round, given your Sufficiently Smart compiler, it
    should be possible to approach it. Whether a Sufficiently Smart CLOS
    compiler happens, however, is again a question of priorities. 

I agree with you, but would like to point out that I don't think the
existence of method combination has any bearing on the issue.  I think
multiple inheritance and slot access are the areas that cause more
performance impact compared to C++.  Furthermore I think the real
performance issues are entirely outside of CLOS, in areas such as
garbage collection and other things that Lisp does for you but C++
does not, and in the fact that the performance comparison is likely
to be on C's "home turf", hardware that is highly adapted for C and
less well adapted for Lisp.

∂23-May-88  1211	Common-Lisp-Object-System-mailer 	Define-Method-Combination 
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I basically agree with Moon's replies to Richard's concerns.
On the topic of the added option to define-method-combination:

	   define-method-combination should accept an option
	   (:generic-function <symbol>) and bind <symbol> to the relevant
	   generic function.

I don't like the name ``:generic-function'' but I cannot think of a
better one. We're moving compute-applicable-methods and function-keywords
into chapter 2 today, so this wrinkle is minor.

			-rpg-

∂23-May-88  1234	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The two functions, compute-applicable-methods and function-arguments,
will appear in chapter 2. The inline code for make-instance will
appear in chapter 3.

			-rpg-

∂23-May-88  1537	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 May 88  15:37:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 409032; Mon 23-May-88 18:37:03 EDT
Date: Mon, 23 May 88 18:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: check-keyword-arguments   
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 May 88 15:34 EDT from Dick Gabriel <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523223659.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 23 May 88  1234 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    The two functions, compute-applicable-methods and function-arguments,
    will appear in chapter 2. The inline code for make-instance will
    appear in chapter 3.

Is the name function-arguments a typo?

∂23-May-88  1539	Common-Lisp-Object-System-mailer 	Comments on current state of Initialization.  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 23 May 88  15:37:56 PDT
Received: by labrea.stanford.edu; Mon, 23 May 88 15:37:54 PDT
Received: from bhopal.lucid.com by edsel id AA01958g; Mon, 23 May 88 15:29:01 PDT
Received: by bhopal id AA01677g; Mon, 23 May 88 15:32:51 PDT
Date: Mon, 23 May 88 15:32:51 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805232232.AA01677@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 21 May 88 19:04 EDT <19880521230422.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Comments on current state of Initialization.

re:     Date: Sat, 21 May 88 06:44:29 PDT
        From: Jon L White <edsel!jonl@labrea.stanford.edu>

        Why should there still  be three initialization protocls: "shared-
        initialize", "initialize-instance",  and "reinitialize-instance"?

        [Summary: replace reinitialize-instance with a keyword argument to
        initialize-instance --Moon]

    Two reasons come immediately to mind: shared-initialize is also used when a
    class is redefined or change-class is called; . . . 

It seemed obvious to me that the "internal" callers from change-class etc. 
could just as easily use a simpilifed definition of initialize-instance with 
keyword argument.


-- JonL --

∂23-May-88  1600	Common-Lisp-Object-System-mailer 	check-keyword-arguments etc.   
To:   moon@STONY-BROOK.SCRC.SYMBOLICS.COM,
      common-lisp-object-system@SAIL.Stanford.EDU
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>


  From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
  Subject: check-keyword-arguments   

    Date: 23 May 88  1234 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    The two functions, compute-applicable-methods and function-arguments,
    will appear in chapter 2. The inline code for make-instance will
    appear in chapter 3.

 Is the name function-arguments a typo?

Yes.  It is called function-keywords in the draft that just went out
to the printers.

There are new chapter 2 files out on sail with these additions.
There is also a new macros file that should fix the [Primary Method]
formatting bug.

-lgd

∂23-May-88  1633	Common-Lisp-Object-System-mailer 	check-keyword-arguments   
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


function-arguments is a typo for function-keywords. That's what I get
for talking on the phone while typing mail.

			-rpg-

∂23-May-88  1649	Common-Lisp-Object-System-mailer 	Re: Mlynarik's comments   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  16:49:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAY 88 16:46:23 PDT
Date: Mon, 23 May 88 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Mlynarik's comments  
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 21 May 88 00:17 PDT from Dick Gabriel
 <RPG@SAIL.Stanford.EDU>
Message-ID: <19880523234612.1.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: 21 May 88 00:17 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    Richard writes:

    ``1-22 2nd PP in `Intro to methods':  The first and second sentences
    seem to be too directly contradictory.  I would change the first to
    ``A method object is not NECESSARILY a function an IN GENERAL cannot be
    invoked as a function.'' ''

    The sentences in question are:

    ``A method object is not a function and cannot be invoked as a function.  An
    implementation may extend the \OS\ so that method objects are functions.''

    The reason it is stated this way is that no one writing portable code can
    take them to be functions, but we do not require them to not be functions
    in all implementations.  

Actually, the second sentence is wrong.  We do prohibit them from being
functions in all implementations.  Chapter 3 is very clear on this
issue.  Methods are instances of the class standard-method which itself
is an instance of standard-class.  We should delete the second sentence.
-------

∂23-May-88  1659	Common-Lisp-Object-System-mailer 	Chapter 1  
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


The versions of Chapter 1 that are being sent to X3J13 are now
on [cls,lsp] on SAIL. You know what it is; you know what to do.

			-rpg-

∂23-May-88  2332	Common-Lisp-Object-System-mailer 	Method Objects are not Functions    
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I don't understand the reasoning that would argue that a method
object a priori cannot be a function.

			-rpg-

∂24-May-88  1044	Common-Lisp-Object-System-mailer 	Re: Method Objects are not Functions     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 May 88  10:44:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 24 MAY 88 10:43:29 PDT
Date: Tue, 24 May 88 10:43 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Method Objects are not Functions    
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: common-lisp-object-system@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: The message of 23 May 88 23:32 PDT from Dick Gabriel
 <RPG@SAIL.Stanford.EDU>
Message-ID: <19880524174313.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: 23 May 88 23:32 PDT
    From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

    I don't understand the reasoning that would argue that a method
    object a priori cannot be a function.

The metaclass of a method object is standard-class.  Standard-class does
not support the behavior which allows its metainstances to be
funcallable objects.  Only funcallable-standard-class does that.

I suppose that some implementation could extend standard-class to do
that, but I don't see that as a freedom we really need to allow.
-------

∂24-May-88  1105	Common-Lisp-Object-System-mailer 	Callable Methods
To:   common-lisp-object-system@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I am aware of the proposed ontology of method objects, but I think we need
to carefully think about how much of the hierarchy to uniquely specify in
Ch3.  That is, method objects are things that on the surface could be
callable. Therefore, maybe the metaclass should be something distinct from
from standard-class, but with the proviso that it is acceptable to either
identify this metaclass with standard-class or to hang it under
funcallable-standard-class.

			-rpg-

∂26-May-88  1055	Common-Lisp-Object-System-mailer 	with-added-methods   
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 26 May 88  10:54:57 PDT
Received: from PERON.AI.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 26 May 88 13:55-EDT
Date: Thu, 26 May 88 13:58 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Subject: with-added-methods
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19880526175838.6.MLY@PERON.AI.MIT.EDU>

[Apologies if I am rehashing an issue which has been previously discussed
-- the local CLOS archives are presently inaccessible.]

with-added-methods seems incompatible with the restriction (mentioned in
the doc for add-method) that a method can only be added to one generic
function at a time.

The doc for with-added-methods says:
  Each generic function is created by adding the set of methods
  specified by its method definitions to a copy of the lexically visible
  generic function of the same name and its methods.
That for add-method says:
  If the method object is a method object of another generic function,
  an error is signaled.

I would think that the new generic function created by
with-added-methods must share all all the methods which were defined on
the original generic function.

I suppose that an alternate reading of the first piece of documentation
is ``to a copy of the lexically visible generic function of the same
name and TO A COPY OF its methods'' -- I'd like to think that this isn't
what was intended, since it would seem to introduce far more problems
than it solves.

Some passing remarks about with-added-methods:
 * Does it really need to be a special form rather than a macro?
   I -believe- I could define it in terms of generic-flet -- however,'
   I haven't thought this through very thoroughly.
 * Is there sufficient Chapter 3 support to enable this kind of thing to
   be `portably' implemented?  Apart from the above-mentioned lossage
   involving methods added to more than one generic function, there are
   problems brushed under the rug by ``A COPY OF the lexically
   visible generic function.''  Presumably there needs to be some
   cloning method for generic functions.
 * I guess I'll never actually use with-added-methods in any case
   because of inefficiencies due what I perceive as the fatal problem
   with method-combination...

∂02-Jun-88  1329	Common-Lisp-Object-System-mailer 	[David N Gray <Gray@DSG>:  making structures] 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Jun 88  13:29:15 PDT
Received: by ti.com id AA14212; Thu, 2 Jun 88 15:28:26 CDT
Received: from Jenner by tilde id AA23256; Thu, 2 Jun 88 15:26:36 CDT
Message-Id: <2790274788-645613@Jenner>
Date: Thu, 2 Jun 88  15:19:48 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: Common-lisp-object-system@sail.stanford.edu
Subject: [David N Gray <Gray@DSG>:  making structures]

I thought I'd pass this along. There is no need to include Gray in the 
reply since he is out of town for two month.

------- Forwarded Message


Patrick,
The May 23 draft of the CLOS spec still has the following text on page
1-15:  "Calling MAKE-INSTANCE to create an instance of STRUCTURE-CLASS
signals an error."  This still seems like an undesirable and unnecessary
limitation to me.
  -- David Gray

------- End of Forwarded Message

∂20-Jun-88  1330	Common-Lisp-Object-System-mailer 	Compile-file environment  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Jun 88  13:30:19 PDT
Received: by ti.com id AA24079; Mon, 20 Jun 88 15:27:31 CDT
Received: from Jenner by tilde id AA06995; Mon, 20 Jun 88 15:17:37 CDT
Message-Id: <2791829681-8355429@Jenner>
Date: Mon, 20 Jun 88  15:14:41 CDT
From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
To: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Compile-file environment


In order to compile in advance (compile-file time ) some implementation
aspects of CLOS metaobjects, there must be some clos metaobjects
residing in an implementation dependent environment, that do not visibly
side effect the runtime environment.  The visible entry points to this
environment come from name to object mapping (FIND-CLASS and
ENSURE-GENERIC-FUNCTION).  I propose that a runtime environment CLOS
object cannot visibly point to a compile-file environment object(No
visible cross environment links).  I think that makes metaclass
programming a lot easier.

Environment Capture
When compiling CLOS DEF..  forms, a evaluation must take place that
affects the compile-file environment, and this evaluation must be a
similar to what happens when the forms are evaluated. 
I propose that the standard expansion of the DEF... macro be:

(defclass foo () ())
 =>
(eval-when (load eval compile)
  (add-named-class (class-prototype (find-class "STANDARD-CLASS"
                                                (name-environment env)))
	                 :name 'foo
                         :environment (name-environment env)))

Where name-environment take the value of a macroexpand environment and
returns the right environment for the right situation.  The value
returned by name-environment can be passed as the environment argument
to all CLOS functions that accept and environment argument.

Presumably, when evaluated in the EVAL and COMPILE-TO-CORE situation,
this name-environment returns NIL (the runtime environment).  When
evaluated in the COMPILE-FILE environment, it returns the compile-file
environment.  When evaluated in LOAD situation, it returns the runtime
environment.  Since the compiler and the evaluator have to treat this
function differently, Logically, this is a special form.


Environments behavior
The compiler should be responsible for implementing the inheritance and
shadowing  of objects in different environments.  However, find-class
should not return a runtime object when the environment argument points
to a compile-file environment.  This avoids cross references across
environments.  I don't think this is a good idea for FIND-CLASS to
return a created class object when an inheritance has to happen.  I
think that should be explicitly done by calling MAKE-DEFAULT-METAOBJECT.

MAKE-DEFAULT-METAOBJECT metaobject-prototype name &optional environment.  Generic-function

The default method on standard-class returns
a forwarded-class when the environment is a runtime environment, and
does the implementation dependent environment inheritance or
forwarded-class creation if the environment is a compile-file
environment. 

Inside of ADD-NAMED-CLASS, MAKE-DEFAULT-METAOBJECT is called when (find-class
class-name nil environment) returns NIL.

Inside of ADD-NAMED-METHOD (or something like that), during the
normalization of the specializers,MAKE-DEFAULT-METAOBJECT needs to be
called if (find-class class-name nil environment) returns NIL when the
environment is a compile-file environment.

Inside of ENSURE-GENERIC-FUNCTION, we need to have the same mechanism.
Either we extend FBOUNDP to accept an environment argument, or we come
up with an equivalent of FIND-CLASS, does not matter much.

MAKE-DEFAULT-METAOBJECT is specialized on standard-generic-function and
returns the appropriate generic function object.

Patrick.

∂22-Jun-88  1448	Common-Lisp-Object-System-mailer 	SYMBOL-MACROLET-UTILITY   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Jun 88  14:46:14 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA21530; Wed, 22 Jun 88 14:46:01 PDT
Message-Id: <8806222146.AA21530@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Date: 22 Jun 88 17:38
To: Common-Lisp-Object-System@sail.stanford.edu
Subject: SYMBOL-MACROLET-UTILITY

I'm getting to ready to submit this as a cleanup proposal; I thought I'd run
it by here first.  My intent in submitting the proposal for cleanup is to open
the discussion of whether SYMBOL-MACROLET is really a desirable language
feature.  If it is resolved that SYMBOL-MACROLET is worth keeping, I have a
follow-up proposal to at least make it a special form.

/JEP
===============================================================================
Status:		DRAFT
Issue:		SYMBOL-MACROLET-UTILITY
References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category:	DELETION
Edit history:	21-Jun-88, Version 1 by Piazza

Problem Description:

    Anything expressible with SYMBOL-MACROLET could also be written with
    regular MACROLET, except that the macro symbol could not stand alone as an
    expression; it would have to be enclosed in parentheses.  The cost
    associated with implementing and maintaining the SYMBOL-MACROLET feature
    exceeds this incremental utility.

Proposal (SYMBOL-MACROLET:FLUSH):

    Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.

Rationale:

    Flushing SYMBOL-MACROLET eliminates the cost of implementing and
    maintaining this feature, while MACROLET still provides most of
    SYMBOL-MACROLET's expressive power.

------------------------------------------------------------------------------

Current Practice:

    Portable Common Loops provides a code-walking implementation of
    SYMBOL-MACROLET as specified in 88-002R.

Cost to Implementors:

    Presumably few implementors have implemented SYMBOL-MACROLET, excepting
    the implementation provided by PCL.  If it is flushed from the language,
    no one will incur any implementation cost.

Cost to Users:

    Users will lose the expressive ability provided by SYMBOL-MACROLET,
    WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.

Cost of Non-Adoption:

    Implementors must implement significant new functionality, adding to
    system size and language complexity.  (A separate proposal,
    SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
    specified semantics of SYMBOL-MACROLET.)

Benefits:

    SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
    a Common Lisp implementation.  It also simplifies the language by
    eliminating the concept of a "symbol macro."

Aesthetics:

    There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
    as a construct in the language.  Some feel it hairs up the language while
    offering only trivial benefit beyond what is already provided through
    normal macros.  Others herald it as a important new language feature.

Discussion:

    As it was adopted by X3J13 as part of CLOS, there has been no formal
    discussion on the pros and cons SYMBOL-MACROLET on its own.

∂24-Jun-88  1225	Common-Lisp-Object-System-mailer 	which functions should be generic?  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  12:25:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:20:08 PDT
Date: 24 Jun 88 12:19 PDT
From: Masinter.pa@Xerox.COM
Subject: which functions should be generic?
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <880624-122008-5902@Xerox>


Mr. Ida asks (relative to COERCE-INCOMPLETE):

"Will Coerce function be a (standard) generic function ?"


I'd like to generalize this: Now that CLOS is part of the standard, which
functions in CL should be generic?

∂24-Jun-88  1332	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  13:31:53 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA28747; Fri, 24 Jun 88 13:30:10 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA18466; Fri, 24 Jun 88 13:26:07 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA07800; Fri, 24 Jun 88 13:30:29 PDT
Message-Id: <8806242030.AA07800@suntana.sun.com>
To: Masinter.pa@Xerox.COM
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic? 
In-Reply-To: Your message of 24 Jun 88 12:19:00 -0700.
             <880624-122008-5902@Xerox> 
Date: Fri, 24 Jun 88 13:30:26 -0700
From: kempf@Sun.COM


1) All the sequence functions (Chapter 14)

2) Stream functions and output functions which use streams
(Chapters 21 & 22). Even though, or perhaps because, extensible
streams are not yet part of the CLOS draft, generic output
functions would be useful.

		jak


		

∂24-Jun-88  1545	Common-Lisp-Object-System-mailer 	which functions should be generic?  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  15:44:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424437; Fri 24-Jun-88 18:44:06 EDT
Date: Fri, 24 Jun 88 18:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: which functions should be generic?
To: Masinter.pa@Xerox.COM
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <880624-122008-5902@Xerox>
Message-ID: <19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 24 Jun 88 12:19 PDT
    From: Masinter.pa@Xerox.COM

    Mr. Ida asks (relative to COERCE-INCOMPLETE):

    "Will Coerce function be a (standard) generic function ?"

It's difficult to implement COERCE's dispatch in terms of generic
function dispatch since equivalence of type specifiers is not done
in an object-oriented way.  There is no way to write a method that
is applicable both for (coerce '(#\a) 'string) and for
(coerce '(#\a) '(vector string-char)), even though both of those
forms mean the same thing.

    I'd like to generalize this: Now that CLOS is part of the standard, which
    functions in CL should be generic?

I think this is the wrong mailing list to discuss changes that X3J13, or
anyone else, might want to make to the language in order to take advantage
of CLOS.

∂24-Jun-88  1648	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from Score.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Jun 88  16:48:51 PDT
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Fri 24 Jun 88 16:50:28-PDT
Received: from hplms2.HP.COM (hplms2) by hplabs.HP.COM with SMTP ; Fri, 24 Jun 88 15:39:09 PST
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.HP.COM; Fri, 24 Jun 88 16:38:46 pdt
Received: from hplwhh by hplwhh.HPL.HP.COM; Fri, 24 Jun 88 16:37:05 pdt
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: which functions should be generic? 
X-Mailer: mh6.5
In-Reply-To: Your message of Fri, 24 Jun 88 18:43:00 -0400.
             <19880624224355.3.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Fri, 24 Jun 88 16:37:03 PDT
Message-Id: <6353.583198623@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

> It's difficult to implement COERCE's dispatch in terms of generic
> function dispatch since equivalence of type specifiers is not done
> in an object-oriented way. 

This could be handled in the same way as the PRINT-OBJECT generic function.
Implementations are required to call it from within their print system.
One could supply a COERCE-OBJECT generic function which the COERCE function
would ultimately call if the coercion argument named a class.  

I realize that one could probably find a large number of candidates in CLtL
to be made generic.  Ideally EQUAL should be generic too.  It already
depends on the type of objects you give it, looking inside of vectors, etc.
Why not allow it to look inside of objects in an object dependent way?

At some point the argument boils down to an efficiency consideration.  I
don't think anyone would be happy if EQ was required to be generic.  There
should be a strong rational for which functions are to be made generic and
which are not.  (For example:  how should the average user know when to use
ELT instead of SVREF?)  Perhaps a generic layer of CL is in order.  CL
already kind of does this with its sequence operations.  I can think of three
generic protocols off hand:

	- sequences which access subcomponents by position

	- objects and structures which access subcomponents by name

	- math functions which operate on generic "numbers"

It would be nice if CL had facilities for formally specifying the protocols
for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
protocol objects, or an abstract-class metaclass), and allow individual
classes to implement a protocol.  This way the user can write code that
meets a protocol without regard to the specifics of its implementation.

∂25-Jun-88  1204	Common-Lisp-Object-System-mailer 	Re: which functions should be generic?   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Jun 88  12:04:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424648; Sat 25-Jun-88 15:01:44 EDT
Date: Sat, 25 Jun 88 15:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: which functions should be generic? 
To: Warren Harris <harris%hplwhh@hplabs.HP.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <6353.583198623@hplwhh>
Message-ID: <19880625190143.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 24 Jun 88 16:37:03 PDT
    From: Warren Harris <harris%hplwhh@hplabs.HP.COM>

    > It's difficult to implement COERCE's dispatch in terms of generic
    > function dispatch since equivalence of type specifiers is not done
    > in an object-oriented way. 

    This could be handled in the same way as the PRINT-OBJECT generic function.
    Implementations are required to call it from within their print system.
    One could supply a COERCE-OBJECT generic function which the COERCE function
    would ultimately call if the coercion argument named a class.  

But it's meaningful for COERCE's second argument to be a type specifier that
does not name a class.  CLtL gives as an example (vector (complex short-float)).
It would be inconsistent to do some coercions with classes and others through
some other mechanism.  I don't think your idea will work without a larger
recasting of Common Lisp in object-oriented terms.  While that's an interesting
project for investigation, I suspect it would quickly go way beyond the
proper charter of a standardization effort.

    It would be nice if CL had facilities for formally specifying the protocols
    for abstract classes like NUMBER, SEQUENCE, or OBJECT (i.e. first class
    protocol objects, or an abstract-class metaclass), and allow individual
    classes to implement a protocol.  This way the user can write code that
    meets a protocol without regard to the specifics of its implementation.

While I strongly agree with this, and have thought so for several years, again
I feel this is beyond the proper charter of a standardization effort.  There
does not appear to be any current practice at all, let alone a concensus from
which to build a standard.

Some of the directions in which I feel Lisp ought to evolve in the 1990s
include enormously better tools for modularity and program packaging,
like what such languages as Ada have but better conceived and (as always
in Lisp) more flexible (the "locales" found in some dialects in Scheme
might be a good place to start); formal notions of protocols and
machine-understandable interface specifications; complete integration of
database concepts into the language; and development tools that
"understand" both Lisp programming concepts and the dynamics of large
development teams.  None of this is X3J13's business, which is to
stabilize the Lisp of the 1980s so people can use it.

∂03-Jul-88  1051	RPG 	The Law of Demeter  
 ∂28-Jun-88  2050	Owners-commonloops.pa@xerox.com 	The Law of Demeter    
Received: from parcvax (PARCVAX.XEROX.COM) by SAIL.Stanford.EDU with TCP; 28 Jun 88  20:50:43 PDT
Received: by parcvax (5.54/1.15) 
	id AA11667; Tue, 28 Jun 88 20:11:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 28 JUN 88 20:07:53 PDT
Return-Path: <RPG@SAIL.Stanford.EDU>
Redistributed: commonloops.pa
Received: from SAIL.Stanford.EDU ([10.0.0.11]) by Xerox.COM ; 28 JUN 88 20:06:52
 PDT
Message-Id: <uqAwE@SAIL.Stanford.EDU>
Date: 28 Jun 88 20:06 PDT
From: Dick Gabriel <RPG@sail.stanford.edu>
Subject: The Law of Demeter  
To: commonloops.pa@xerox.com

I just wrote a poem that helps explain the Law of Demeter (apologies
to Wallace Stevens):

Thirteen Ways of Looking at the Law of Demeter

	I
Among twenty snowy mountains,
The only moving thing
Was the Speaker of the Law.

	II
I was of three minds,
Like a program
In which there are three violations.

	III
The Sheet of the Law whirled in the autumn winds.
It was a small part of the pantomime.

	IV
A message and an argument
Are one.
A message and an argument and the Law
Are one.

	V
I do not know which to prefer,
The beauty of inflections
Or the beauty of innuendos,
The Law speaking
Or just after.

	VI
Icicles filled the long window
With barbaric glass.
The shadow of the Speaker
Crossed it to and fro.
The mood
Traced in the shadow
An indecipherable cause.

	VII
O thin men of Haddam,
Why do you imagine golden birds?
Do you not see how the Law
Walks around the feet
Of the programs about you?

	VIII
I know noble accents
And lucid, inescapable rhythms;
But I know, too,
That the Law is involved
In what I know.

	IX
When the Law disappeared from sight,
It marked the edge
Of one of many circles.

	X
At the sight of the Law
Working in green light,
Even the bawds of euphony
Would cry out sharply.

	XI
He rode over Connecticut
In a glass coach.
Once, a fear pierced him,
In that he mistook
The shadow of his equipage
For a violation.

	XII
The river is moving.
The Law must be working.

	XIII
It was evening all afternoon.
It was snowing.
And it was going to snow.
The Law sat 
On a sheet of paper.

∂11-Jul-88  1111	CL-Object-Oriented-Programming-mailer 	CLOS Workshop   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jul 88  11:11:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUL 88 11:06:55 PDT
Date: Mon, 11 Jul 88 11:02 PDT
From: Gregor.pa@Xerox.COM
Reply-To: Gregor@GRAPEVINE.parc.xerox.com
Subject: CLOS Workshop
To: Common-Lisp@Sail.Stanford.edu, common-lisp-object-system@sail.stanford.edu,
 CL-Object-Oriented-Programming@Sail.Stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
Message-ID: <19880711180221.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no



       Workshop for CLOS Users and Implementors

                October 3rd and 4th

                    Xerox PARC

               Palo Alto, California


We have been excited by the extent to which CLOS is already being
used, and the ways in which it is being extended.  The purpose of
this workshop is to provide an opportunity for the members of the
CLOS community to get together and share their experience.

To provide a good start for the interchange, we are requesting that
participants supply a short position paper (1-3 pages) describing
work related to CLOS.  Some topics of interest are:

      Applications
      Programming Techniques
      Implementation
      Programming Environment Tools
      Extensions of CLOS
      Techniques for Converting to CLOS
      Meta Object Techniques and Theory
      Critiques

We will try to support demonstrations or videotapes of applications,
programming environments, implementations or other relevant systems.

If you are planning to attend, please let us know by August 15th.
This will help us with planning and allow us to arrange a discount
rate at a local hotel.

Position papers should reach us by September 9th so that we can
organize a program and arrange for duplication of the papers.

Position papers, notice to attend, and other correspondence should
be sent to: 

     Gregor Kiczales
     3333 Coyote Hill Rd.
     Palo Alto, CA 94304

or by Internet mail to:
  
     Gregor.pa@Xerox.com
-------

∂15-Jul-88  1304	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88  13:04:09 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA27189; Fri, 15 Jul 88 13:02:05 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA05872; Fri, 15 Jul 88 13:02:42 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA07423; Fri, 15 Jul 88 12:42:03 PDT
Date: Fri, 15 Jul 88 12:42:03 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807151942.AA07423@lukasiewicz.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: putting CLOS objects in binfiles

It's a shame that there's no provision in CLOS for
saving objects in binfiles.  It's going to blow up
in our faces when CLOS gets ubiquitous enough for
people to use CLOS objects without being aware of it.
(I.e., when lower layers of layered products use
CLOS without advertising the fact.)

The reason is that the default object fasdumper
does a GC-style walk over the object, dumping not
only the object but also its class hierarchy.
Saving one object got me a binary file of over 100Kb.
(In Lucid 3.0.)

People expect to use binary files to store data in!
If CLOS objects can't be dumped, it will effectively
mean that you can't store data in Common Lisp binary files.

It's like that ancient MIT story about Lisp packages:
The first time they tried to fasdump a package object,
much of the Lisp world went along with it.  This kind
of behavior has to be fixed in real systems.  (As
with our future unaware user of CLOS, the MIT package
fasdump meltdown happened unexpectedly.  A bare "FOO:"
used to mean the FOO package object, instead of its present
meaning.)

Can a fix for this get sneaked into Chapter 3 of
the CLOS spec?

Here's essentially what's needed:  A generic function
(called, say, RECONSTRUCTOR-FORM) which returns a
Lisp form to evaluate to reconstruct any given
object.  It can return NIL, which means to do
some system default, like a GC-style walk.
The reconstructor form would be stored in
lieu of the real object into the binary file,
adorned with #, for evaluation at load time.

A different way to factor things would be to
have a function RECONSTRUCTOR-INITS which
computes at dump time a class name and keyword/value
plist, and a function RECONSTRUCT-INSTANCE analogous
to and equivalent by default to MAKE-INSTANCE,
which is called at load time on the saved data.

The fasdumper (and other utilities, like an object
migrator) could use protocols like these to handle
user-defined types correctly.

Using #, is not a solution:  A fasdumper needs to
correctly handle CLOS objects wherever they occur
in the data structures being dumped.

Here's my immediate problem:  I want to build objects
which represent predicates in a special purpose query
language, and I want them to be uniquified, like pathnames
on the Lisp Machine.  (They cache things like compiled Lisp
code, so it's expensive to build new copies.)  Such things
do not dump properly, and even if a simple patch were to
be applied (say, to dump a class symbol instead of a class),
a simple-minded load routine would not uniquify them.

			-- John

∂15-Jul-88  1408	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jul 88  14:08:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434003; Fri 15-Jul-88 17:07:46 EDT
Date: Fri, 15 Jul 88 17:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles
To: John Rose <jrose@Sun.COM>
cc: common-lisp-object-system@SAIL.STANFORD.EDU
In-Reply-To: <8807151942.AA07423@lukasiewicz.sun.com>
Message-ID: <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 15 Jul 88 12:42:03 PDT
    From: jrose@Sun.COM (John Rose)

    It's a shame that there's no provision in CLOS for
    saving objects in binfiles.

CLOS doesn't address this because Common Lisp doesn't.
Note that CL provides no way to write a "binfile" other than
COMPILE-FILE.  Of course you can trick COMPILE-FILE into
doing anything, using macros, so that's no real limitation.

    The reason is that the default object fasdumper
    does a GC-style walk over the object, dumping not
    only the object but also its class hierarchy.

That's a statement about some particular implementation,
not about Common Lisp.

    Can a fix for this get sneaked into Chapter 3 of
    the CLOS spec?

Chapter 3 would be the wrong place.  This is logically
a Chapter 2 facility, in the same vein as PRINT-OBJECT.

The status of CLOS is that it has been accepted by X3J13
into the same status as CLtL.  This means that it is open to
cleaning up and improvement through the normal X3J13
mechanisms, and I think your suggestion makes a great deal
of sense and should be done through those mechanisms.  Do
you want to make the proposal (I don't know if you're
familiar with X3J13), or do want to ask someone on the
CLOS committee to do it?

    Here's essentially what's needed:  A generic function
    (called, say, RECONSTRUCTOR-FORM) which returns a
    Lisp form to evaluate to reconstruct any given
    object.  

This is fine.  It's how Flavors does it, so there is some
precedent.  The only problem with this technique is that it
doesn't cope well with circular structures, which can only
be handled by separating creation of the objects from filling
them in (and even that doesn't work in general, for reasons
too complicated to get into here).

	     It can return NIL, which means to do
    some system default, like a GC-style walk.

I think this is a really bad idea.  My experience is that there is no
default that is right for all objects and any attempt to offer a default
does users more harm than good, because the default gets used for cases
where it can't work any causes hard to understand problems.
Furthermore, if there was a default, it should be implemented by a
default method for the generic function, not by special-casing NIL.  I'd
prefer that there be no default and hence if the user has not defined a
method, an error is signalled.

    Here's my immediate problem:  I want to build objects
    which represent predicates in a special purpose query
    language, and I want them to be uniquified, like pathnames
    on the Lisp Machine.  (They cache things like compiled Lisp
    code, so it's expensive to build new copies.)  Such things
    do not dump properly, and even if a simple patch were to
    be applied (say, to dump a class symbol instead of a class),
    a simple-minded load routine would not uniquify them.

I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.  You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly.
I think most implementations do guarantee object identity within
a single COMPILE-FILE, even though they're not required to.
This is not a CLOS issue, it applies to all objects for which EQ
is defined.

∂15-Jul-88  1719	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jul 88  17:19:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUL 88 17:08:30 PDT
Date: 15 Jul 88 17:08 PDT
From: Bobrow.pa@Xerox.COM
Subject: Re: putting CLOS objects in binfiles
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Fri, 15 Jul 88 17:07 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jrose@Sun.COM, common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <880715-170830-1592@Xerox>

   Here's my immediate problem:  I want to build objects
    which represent predicates in a special purpose query
    language, and I want them to be uniquified, like pathnames
    on the Lisp Machine.  (They cache things like compiled Lisp
    code, so it's expensive to build new copies.)  Such things
    do not dump properly, and even if a simple patch were to
    be applied (say, to dump a class symbol instead of a class),
    a simple-minded load routine would not uniquify them.

"I'm not sure that anything in Common Lisp requires that multiple
references to a single object, in a file being compiled, do not
turn into multiple objects when the file is loaded.  You might have
to address this in an implementation-dependent way unless the
definition of Common Lisp were changed to require this explicitly."

In Loops, the way we solved this problem was to provide each savable object a
unique identifier.  This UID was constructed from some representation of the
machine of ceation and the time of creation.  An object knows its UID, and from
the UID one can find the object.  For any object, the form that was dumped
includes its UID, as well as its contents.  References from a dumped object to
another object contain a form which reconstructs the pointer to object referred
to, but does not try to reconstruct its contents.  

Suppose we had an objects O1 and O2, of classes FOO and FIE respectively, each
with one slot named OTHER pointing to the other object.  Then  dumping them to a
file might create expressions like:

#,(reconstruct-object uid1 FOO OTHER #.(pointer-to-object uid2 FIE))

#,(reconstruct-object uid2 FOO OTHER #.(pointer-to-object uid1 FOO))

The result of evaluating (pointer-to-object uid2 FIE) is to create an
uninitialized object of class FIE, and make it be the value of the slot OTHER of
O1.  O1 is the object created by the first reconstruct-object form, with UID
uid1.  Evaluating the second reconstruct-object form changes the contents of the
uninititialized object.  Evaluating the form (pointer-to-object uid1 FOO) finds
the first object created.

As far as tracing through objects, we found it was better to separate out the
process of finding all objects that you want dumped (a user defined trace that
creates a list).  One then dumps each of the listed objects.  Stan Lanning
implemented a preliminary CLOS version that we have been experimenting with.
 

∂18-Jul-88  0808	Common-Lisp-Object-System-mailer 	Re: putting CLOS objects in binfiles     
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88  08:08:54 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA22842; Mon, 18 Jul 88 08:06:28 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15584; Mon, 18 Jul 88 08:07:04 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18158; Mon, 18 Jul 88 08:06:20 PDT
Message-Id: <8807181506.AA18158@suntana.sun.com>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: John Rose <jrose@Sun.COM>, common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: putting CLOS objects in binfiles 
In-Reply-To: Your message of Fri, 15 Jul 88 17:07:00 -0400.
             <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Mon, 18 Jul 88 08:06:17 -0700
From: kempf@Sun.COM

>I'm not sure that anything in Common Lisp requires that multiple
>references to a single object, in a file being compiled, do not
>turn into multiple objects when the file is loaded.  You might have

Yes, in fact, there is one Common Lisp implementation in which references
to vectors are not EQ after loading. After looking through selected sections
of CLtL, no guarantees seem to be made about preserving EQness between compile
time and run time.

			jak

∂18-Jul-88  1307	Common-Lisp-Object-System-mailer 	putting CLOS objects in binfiles    
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88  13:07:13 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA29734; Mon, 18 Jul 88 13:04:21 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA29199; Mon, 18 Jul 88 13:04:51 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA18995; Mon, 18 Jul 88 13:06:16 PDT
Date: Mon, 18 Jul 88 13:06:16 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8807182006.AA18995@lukasiewicz.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Bobrow.pa@Xerox.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Cc: jrose@Sun.COM
In-Reply-To: David A. Moon's message of Fri, 15 Jul 88 17:07 EDT <19880715210732.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: putting CLOS objects in binfiles

   Date: Fri, 15 Jul 88 17:07 EDT
   From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Fri, 15 Jul 88 12:42:03 PDT
       From: jrose@Sun.COM (John Rose)

       It's a shame that there's no provision in CLOS for
       saving objects in binfiles.
     ...
       Here's essentially what's needed:  A generic function
       (called, say, RECONSTRUCTOR-FORM) which returns a
       Lisp form to evaluate to reconstruct any given
       object.  

   This is fine.  It's how Flavors does it, so there is some
   precedent.  The only problem with this technique is that it
   doesn't cope well with circular structures, which can only
   be handled by separating creation of the objects from filling
   them in (and even that doesn't work in general, for reasons
   too complicated to get into here).
  ...
OK, I'd like to create a proposal.  I understand my hallmate
Cris Perdue is thinking about binfiles, so I'll talk with him
some first.

To deal with circularities, one can separate the object creation
protocol into two passes, one to create a reference to an uninitialized
object (which can be used to plug into other structures), and a second
pass to initialize the object itself.  You say there are in
general problems here, and I imagine you are referring to
the window between the two passes, when the object can be
referenced, but might not yet contain valid data.  Do you
think this problem can be addressed adequately as follows:

  At dump time, if circularities are detected, the target
  of a back-arc (which will need to be created in two passes
  at load time) is passed to a generic function (named, e.g.,
  CIRCULAR-RECONSTRUCTOR-FORMS) which either generates parameters
  for the two load time passes, or signals an error at dump time.

This would allow a class to disallow all or some circularities,
or handle them in a class-specific manner, by gaining some control
over the window between the two load time passes.  An object
in the inter-pass window could even have a different class; pass 2
could perform a CHANGE-CLASS.

Also, let me make another stab at a default behavior for dumping:
Use the PRINT-OBJECT printer, and save the string the binary file.
Proper use of a *PRINT-READABLY* flag would be required to detect errors,
and recursive calls to PRINT-OBJECT would have to transfer
control to the binary dumper (leaving a #<n># or similar
notation in the object's string).  The advantage of this
default is that the class writer need only code a readable
PRINT-OBJECT representation, and not worry about binary files
explicitly.

       Here's my immediate problem:  I want to build objects
       which represent predicates in a special purpose query
       language, and I want them to be uniquified, like pathnames
       on the Lisp Machine.  (They cache things like compiled Lisp
       code, so it's expensive to build new copies.)  Such things
       do not dump properly, and even if a simple patch were to
       be applied (say, to dump a class symbol instead of a class),
       a simple-minded load routine would not uniquify them.

   I'm not sure that anything in Common Lisp requires that multiple
   references to a single object, in a file being compiled, do not
   turn into multiple objects when the file is loaded.

Symbols load as single objects.  And on the Lisp Machine (last
time I looked) pathnames were interned in the same way.
I think this is done because symbols and pathnames are
used as names, or references for other objects, and making
them EQ makes for fast comparison, and allows referencing
parties to make shared annotations on the name object.
					       		You might have
   to address this in an implementation-dependent way unless the
   definition of Common Lisp were changed to require this explicitly.
   I think most implementations do guarantee object identity within
   a single COMPILE-FILE, even though they're not required to.
   This is not a CLOS issue, it applies to all objects for which EQ
   is defined.

I'm willing to guarantee object identity myself, if I can only
get control whenever the system thinks it wants to cons one of
my objects, and intern it.  Something like this:
	(LET ((TABLE (MAKE-HASH-TABLE :TEST 'EQUAL)))
	  (DEFMETHOD MAKE-INSTANCE ((EQL 'MYCLASS) &KEY X Y)
	    (LET ((PARAMS (LIST X Y)))
	      (OR (GETHASH PARAMS TABLE)
		  (SETF (GETHASH PARAMS TABLE)
			(CALL-NEXT-METHOD))))))



   Date: 15 Jul 88 17:08 PDT
   From: Bobrow.pa@Xerox.COM

   In Loops, the way we solved this problem was to provide each savable object a
   unique identifier.  This UID was constructed from some representation of the
   machine of ceation and the time of creation.  An object knows its UID, and from
   the UID one can find the object.  For any object, the form that was dumped
   includes its UID, as well as its contents.  References from a dumped object to
   another object contain a form which reconstructs the pointer to object referred
   to, but does not try to reconstruct its contents.  

Wow!  That's neat stuff.  It shows how far we've come that solutions
to the problem of object identity within a single Lisp session are taken
for granted (reread the CLtL chapter on packages if you think it's
no problem) and the current research is into defining and maintaining
uniqueness across much wider domains, such as all machines and times
in some space.

But all I wanted (this time) was uniqueness across a session, and
some sort of transportable printed representation, like symbols or LispM
pathnames.

					-- John

∂26-Jul-88  0847	Common-Lisp-Object-System-mailer 	where I'm going, etc.
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jul 88  08:47:37 PDT
Received: from JUNCO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438595; Tue 26-Jul-88 11:47:05 EDT
Date: Tue, 26 Jul 88 11:46 EDT
From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
Subject: where I'm going, etc.
To: common-lisp-object-system@sail.stanford.edu
Message-ID: <19880726154638.0.SKEENE@JUNCO.SCRC.Symbolics.COM>


I will be leaving Symbolics this Friday, and my new job is not
Lisp-related or CLOS-related.    I'm sorry to say that this means I
won't be able to continue going to meetings at X3J13, or keeping up with
the rest of the CLOS work.    I hope to be able to stay on the CLOS
mailing list at my new company, and maybe help out with editing of the
Meta-object chapter now and then.

I did finish writing my book, about one day after we voted to accept
CLOS.  The book will be available within a couple of weeks.  It's called
"Object-Oriented Programming in Common Lisp:   A Programmer's Guide to
CLOS", and it is being published by Addison-Wesley and Symbolics Press.
I hope everyone will read and enjoy it. 

I have many mixed feelings about leaving this community, especially when
my book is just about to be published, and while there is still much
work to be done on the Meta-object protocol and on the Common Lisp
specification itself.    Certainly, working with the CLOS group has been
a great honor, a wonderful learning experience, and a lot of fun over
the last two years.   

My new job will be a real departure, although it is still in the
computer software field.   The company is called "ITP boston" and they
do factory-automation software.    They are spinning off a company to
develop and market a product, and I'll be leading the documentation 
effort of the new spinoff.

I looked for a job that would allow me to continue my CLOS and Lisp
work, but I didn't find anything that really felt right.   Maybe
something will eventually turn up in that field for me, and you'll see 
me at meetings again.   

In any case, if you're in Boston and want to meet me for lunch or 
dinner, GIVE ME A CALL!  I'd very much like to keep in touch.  If the
phone numbers below change for any reason, ask David Moon where I am.

My home phone is:   617-648-4323 (Arlington, Mass.) 
On August 8, my work phone will be:   617-499-4200 (Cambridge)


∂02-Aug-88  1412	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Aug 88  14:09:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 AUG 88 13:53:08 PDT
Date: Tue, 2 Aug 88 13:51 PDT
From: Gregor.pa@Xerox.COM
Subject: declare in with-slots
To: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
Message-ID: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


We never discussed how people could use declare inside of with-slots.  I
don't think we ever thought of it.  But to at least one of my users,
this is a serious bug.  Here is an idea for how to fix this.  I am not
enough of a declaration expert to know if this can work.

All of what I say here also applies to with-accessors.

Allow declarartions to appear in front of the with-slots body.  These
declarations affect the pseudo-bindings performed by the with slots.
They talk about the value which will be returned by evaluating one of the
pseudo variables and the values which will be stored in the pseudo
variables.  The SPECIAL declaration is, of course, now allowed.

So, for example:

(with-slots (x y z) <instance>
  (declare (fixnum x y z))
  (setq z (* x y)))

Becomes:

(progn
   (setf (the fixnum (slot-value <instance> 'z))
         (* (the fixnum (slot-value <instance> 'x))
	    (the fixnum (slot-value <instance> 'x)))))

If this makes sense, a cleanup proposal should do the trick.

Note that I didn't layer this directly into symbol-macrolet.  We could
of course put it there, but it seemed to me that it was more appropriate
for this to be something which the caller of symbol-macrolet handles.  I
could pretty easily be convinced that I am wrong about this.
-------

∂03-Aug-88  0712	Common-Lisp-Object-System-mailer 	RE: decalre in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  07:12:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03551; Wed, 3 Aug 88 07:10:42 PDT
Date: Wed, 3 Aug 88 07:10:42 PDT
Message-Id: <8808031410.AA03551@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: RE: decalre in with-slots

> We never discussed how people could use declare inside of with-slots.  I
> don't think we ever thought of it. 

My problem all along with with-slots and symbol-macrolet has been that they
haven't been thought through.  It's not simple to mount this charade that slots
are "just like" variables.  I've come in too late on this work to have said
this earlier, but I will predict now that you will find still other problems
with symbol-macrolet as time goes by.


As to the suggested patch:  No, it won't really work.  Declare's are pretty
much the province of special forms, and with-slots et al won't, in general, be
able to parse the declare's, let alone interpret them correctly.  For example,
a common extension to declare allows:

(deftype t-terminated-list () '(or cons (member t)))

(with-slots (x y z) <instance>
  (declare (t-terminated-list y))
  ...)

In Common Lisp, you can't tell that t-terminated-list is a type, and, even if
you could, you couldn't be sure that this meant 
(declare (type t-terminated-list y)).  (It might mean (declare (ftype ...)), 
which would have nothing at all to do with the _variable_ y.)

While you're thinking about this, consider what would happen if Common Lisp
were extended to allow:

(with-slots (x y z) <instance>
  ...
  (locally (declare (fixnum y))
    ...)
  ...)

[CL doesn't currently allow this, but there's some sentiment to make this
extension.]  Now with-slots would have to parse the entire body to get this
right. 
 
> Note that I didn't layer this directly into symbol-macrolet.  We could
> of course put it there, but it seemed to me that it was more appropriate
> for this to be something which the caller of symbol-macrolet handles.  I
> could pretty easily be convinced that I am wrong about this.
 
What's the point of symbol-macrolet, then, if not to be the form which says
"pretend foo is a variable, even though it's not"?  You're suggesting that only
with-slots wants to play "let's pretend," and that there's some different roles
that symbol-macrolet fills?  I doubt it...

/JEP

∂03-Aug-88  0852	Common-Lisp-Object-System-mailer 	RE: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  08:52:40 PDT
Received: by ti.com id AA05029; Wed, 3 Aug 88 10:50:48 CDT
Received: from Kelvin by tilde id AA28918; Wed, 3 Aug 88 10:35:22 CDT
Message-Id: <2795614606-3753982@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 3 Aug 88  10:36:46 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
Cc: Common-Lisp-Object-System@SAIL.Stanford.Edu
Subject: RE: declare in with-slots
In-Reply-To: Msg of Wed, 3 Aug 88 07:10:42 PDT from Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>

I agree with Piazza's sentiment that it is not reasonable to expect
macros to comprehend the semantics of declarations.  This appears to be
another reason why SYMBOL-MACROLET ought to be a special form; then it
could accept declarations, and WITH-SLOTS could just pass them through.
(But I'm not necessarily endorsing the notion that type declarations
need to be supported here.)

  -- David Gray

∂03-Aug-88  1024	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 3 Aug 88  10:24:28 PDT
Received: by labrea.stanford.edu; Wed, 3 Aug 88 10:22:44 PDT
Received: from rainbow-warrior.lucid.com by edsel id AA01559g; Wed, 3 Aug 88 10:18:11 PDT
Received: by rainbow-warrior id AA12130g; Wed, 3 Aug 88 10:19:32 PDT
Date: Wed, 3 Aug 88 10:19:32 PDT
From: Patrick Dussud <edsel!dussud@labrea.stanford.edu>
Message-Id: <8808031719.AA12130@rainbow-warrior.lucid.com>
To: Gregor.pa@xerox.com
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 2 Aug 88 13:51 PDT <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>
Subject: declare in with-slots

   Date: Tue, 2 Aug 88 13:51 PDT
   From: Gregor.pa@Xerox.COM
   Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
   Line-Fold: no


   We never discussed how people could use declare inside of with-slots.  I
   don't think we ever thought of it.  But to at least one of my users,
   this is a serious bug.  Here is an idea for how to fix this.  I am not
   enough of a declaration expert to know if this can work.

   All of what I say here also applies to with-accessors.

   Allow declarartions to appear in front of the with-slots body.  These
   declarations affect the pseudo-bindings performed by the with slots.
   They talk about the value which will be returned by evaluating one of the
   pseudo variables and the values which will be stored in the pseudo
   variables.  The SPECIAL declaration is, of course, now allowed.

   So, for example:

   (with-slots (x y z) <instance>
     (declare (fixnum x y z))
     (setq z (* x y)))

The syntax makes sense.

   Note that I didn't layer this directly into symbol-macrolet.  We could
   of course put it there, but it seemed to me that it was more appropriate
   for this to be something which the caller of symbol-macrolet handles.  I
   could pretty easily be convinced that I am wrong about this.
   -------
I think that it has to be put in symbol-macrolet as well. If not, the work
that has to be done in with-slot is beig enough so the layering is totally
useless. Maybe making with-slots and with-accessors special forms and forget
about symbol-macrolet is a good solution. The context is narrower that we
originally proposed, so the semantics issue will be easier to nail down.

Patrick.

∂03-Aug-88  1150	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 3 Aug 88  11:50:09 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA28905; Wed, 3 Aug 88 11:47:53 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA12009; Wed, 3 Aug 88 11:48:33 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA18770; Wed, 3 Aug 88 11:47:24 PDT
Message-Id: <8808031847.AA18770@suntana.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 03 Aug 88 10:19:32 -0700.
             <8808031719.AA12130@rainbow-warrior.lucid.com> 
Date: Wed, 03 Aug 88 11:47:10 -0700
From: kempf@Sun.COM


I'm not sure I understand what all the fuss is about. Currently in
Common Lisp, the following is not allowed;

	(multiple-value-bind (x y z)
	  (declare (fixnum x y z))
	  (multiple-return-value-function a b c)

	  ...
	)

Seems to me with-slots and with-accessors falls into the same category.
It would, of course, be nice to be able to do the above, just as it
would for with-slots, but the following also works in at least one
CL I've used:

	(multiple-value-bind (x y z)
	  (multiple-return-value-function a b c)

	  (locally 
	    (declare (fixnum x y z))

		...
	  )
	)

As to people not liking with-slots because it is Yet Another Scoping
Mechanism, I feel the same about the multiple value constructs, but
some people like them. 

		jak




∂03-Aug-88  1504	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Aug 88  15:04:50 PDT
Received: by ti.com id AA02329; Wed, 3 Aug 88 17:03:57 CDT
Received: from Kelvin by tilde id AA08593; Wed, 3 Aug 88 16:48:23 CDT
Message-Id: <2795636967-5097451@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 3 Aug 88  16:49:27 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: kempf@SUN.COM
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Msg of Wed, 03 Aug 88 11:47:10 -0700 from kempf@SUN.COM

> I'm not sure I understand what all the fuss is about. Currently in
> Common Lisp, the following is not allowed;
> 
> 	(multiple-value-bind (x y z)
> 	  (declare (fixnum x y z))
> 	  (multiple-return-value-function a b c)
> 
> 	  ...
> 	)

The correct syntax is:

	(multiple-value-bind (x y z)
	    (multiple-return-value-function a b c)
	  (declare (fixnum x y z))

	  ...
	)

> It would, of course, be nice to be able to do the above, just as it
> would for with-slots, but the following also works in at least one
> CL I've used:
> 
> 	(multiple-value-bind (x y z)
> 	  (multiple-return-value-function a b c)
> 
> 	  (locally 
> 	    (declare (fixnum x y z))
> 
> 		...
> 	  )
> 	)

It may be allowed, but it doesn't seem very useful because it doesn't
change the fact that tagged value slots have to be used.

  -- David Gray

∂03-Aug-88  1538	Common-Lisp-Object-System-mailer 	declare in with-slots
Received: from SPAR-20.SPAR.SLB.COM by SAIL.Stanford.EDU with TCP; 3 Aug 88  15:37:54 PDT
Date: Wed, 3 Aug 1988  15:37 PDT
Message-ID: <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>
From: Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>
To:   Gregor.pa@XEROX.COM
Cc:   common-lisp-object-system@SAIL.STANFORD.EDU
Subject: declare in with-slots
In-reply-to: Msg of 2 Aug 1988  13:51-PDT from Gregor.pa at Xerox.COM


One other point to be made with respect to declarations and with-slots is that
the types of the slots may already be declared in the class definition. If a
slot is declared to be fixnum in the defclass, then it should automatically be
treated as such in the body of a with-slots, without having to place another
explicit declaration.

∂04-Aug-88  0828	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 4 Aug 88  08:28:30 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA12267; Thu, 4 Aug 88 08:25:58 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA27693; Thu, 4 Aug 88 08:26:39 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA20536; Thu, 4 Aug 88 08:25:33 PDT
Message-Id: <8808041525.AA20536@suntana.sun.com>
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: common-lisp-object-system@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 03 Aug 88 16:49:27 -0500.
             <2795636967-5097451@Kelvin> 
Date: Thu, 04 Aug 88 08:25:30 -0700
From: kempf@Sun.COM


>The correct syntax is:
>
>	(multiple-value-bind (x y z)
>	    (multiple-return-value-function a b c)
>	  (declare (fixnum x y z))
>
>	  ...
>	)


OK, so how about:

	(with-slots (x y z) obj
	  (declare (fixnum x y z))

	   ...
	)

though, as Glenn Kramer has pointed out, the declaration is actually
redundent because the types can be deduced from the class definition.
Other declarations, like compilation optimization and special declarations,
cannot, however. There is a question of whether those should be allowed.

The expansion of with-slots would be something like:

	(symbol-macrolet
	  ( (x (the fixnum (slot-value 'x obj)))
	    (y (the fixnum (slot-value 'y obj)))
	    (z (the fixnum (slot-value 'z obj)))
	  )
	  (locally
	    <any other declarations>

	    ...
	  )
	)

so the expansion would, indeed, have to check for type declarations on the
pseudovariables. symbol-macrolet does not, however.

If type declarations are allowed, then the question of what to do should
a conflict between the declaration of types in the class and the local
declaration occurs. There are a number of options here, everything from
leaving it up to the implementation to decide to checking if the local
declaration is wider than the declaration in the class (e.g. a local
declaration of number when the class declared the slot to be fixnum)
and signalling an error. Having a narrower declaration (e.g. a
local declaration of fixnum when the class declared the slot to be
number) could have important uses in some cases.

		jak



∂04-Aug-88  1134	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 4 Aug 88  11:34:31 PDT
Received: by ti.com id AA10039; Thu, 4 Aug 88 13:33:30 CDT
Received: from Kelvin by tilde id AA02949; Thu, 4 Aug 88 13:23:04 CDT
Message-Id: <2795711083-4281424@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 4 Aug 88  13:24:43 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: kempf@Sun.COM
Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
Subject: Re: declare in with-slots 
In-Reply-To: Msg of Thu, 04 Aug 88 08:25:30 -0700 from kempf@Sun.COM

> though, as Glenn Kramer has pointed out, the declaration is actually
> redundent because the types can be deduced from the class definition.

That assumes that you know the class of the object expression; the
compiler might know, but a macro would not.  The type lookup could be done
at either the WITH-SLOTS or SYMBOL-MACROLET level, but whichever one does
it would have to be a special form.

  -- David Gray

∂05-Aug-88  1331	Common-Lisp-Object-System-mailer 	description language classes & the Meta-Object Protocol 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Aug 88  13:31:42 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA04593; Fri, 5 Aug 88 13:29:18 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA09117; Fri, 5 Aug 88 13:29:59 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA05986; Fri, 5 Aug 88 12:25:14 PDT
Date: Fri, 5 Aug 88 12:25:14 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8808051925.AA05986@lukasiewicz.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: description language classes & the Meta-Object Protocol

[This is a message which I sent a week and a half ago to the commonloops
mailing list.  I have since learned that this is a more appropriate list
to mail such discussions to, so I'm reposting.  If you've already
seen this, sorry for the redundancy.  I've changed nothing in the message.
				-- John

Original header:
Date: Mon, 25 Jul 88 16:12:16 PDT
To: commonloops.pa@xerox.com]

I'm going to describe a way I'd like to use the Meta-Object Protocol.
Hopefully, readers of this list will either tell me why it's a
misuse, or assure me that the Meta-Object Protocol will support
what I have in mind.

Start with a description language L.  That is, terms in L denote
predicates over some universe U; they describe objects in U.
(You could also call L a pattern language.)  There is some efficient
Lisp function L-APPLY which applies an L-term to a U-object and returns
T or NIL, depending on whether the term describes the object.

There is one other property of L:  There is a Lisp function L-LESSP
which takes any two L-terms t1, t2 and compares them, returning T or NIL,
depending on whether t1 entails t2 for all U-objects.  This is
a partial order on the description language.  Think of it this
way:  Less specific terms are greater than more specific ones.

Finally, define *L-TOP* to be the L-term which is greater than
all other L-terms (the least specific element).

(It is possible and useful to make L into a lattice by adding Lisp
functions L-MEET and L-JOIN, but I don't think that is necessary for
this discussion.)

I'd like to define a Meta-Class L-CLASS which models L.  In particular,
each L-term would correspond to an L-CLASS.  An L-term's L-CLASS would
have as instances all U-objects which match the L-term.  Note that
an L-CLASS does not necessarily support MAKE-INSTANCE:  As befits
a description language, the L-CLASSes merely impose structure on
a pre-existing space of U-objects.

Methods arguments can be specialized with L-CLASS specializers;
such arguments are assumed to be U-objects, and the method
is applied only to arguments that match the specializer.
That is, the L-CLASS protocol wraps the method body with code
which uses L-APPLY to filter out U-objects which don't match
the specializer.  This is just like STANDARD-CLASS dispatching,
except that L-APPLY can interpret L-terms using any algorithm
whatsoever.

If a generic is applied to a U-object, there will in general
be several methods which apply; they must be ordered most
specific first.  The computation of this ordering is done
with the L-LESSP predicate.  This works much like STANDARD-CLASS
method ordering.  When the specializers of applicable methods
are not linearly ordered (this case corresponds to class multiple
inheritance) , the L-CLASS must specify some sort of linearization,
so that CALL-NEXT-METHOD will be useful.

In any case, when a U-object is handed to a generic function
with L-CLASS specializers, only methods with specializers
that correctly describe the U-object are invoked, and then
in a reasonable order determined by description specificity.

You know, object oriented languages supply two very distinct services
that are often confused:  Representation management, and argument
dispatching.  Abstract types can be built from concrete representations,
often drawn from a rich set of possibilities (e.g., C++).  Abstract
functions can be built, piece by piece, from methods, each applicable
to a limited set of arguments; the OOL supplies the glue logic which
makes sure that each method gets the right kinds of arguments.
The distinction between the two services is based on this observation:
It is not necessary that the set of representations be identical
with the set of dispatchable types.  (In practice, it's often useful
to tightly coordinate the two services, since the OOL system can
then optimize representations for fast dispatch.)

Description language classes supply the argument dispatch service
only.  (By contrast, facilities like DEFSTRUCT construct representations
without dispatch services.)

For concreteness, I'll give several examples of description languages
that could be usefully treated as meta-classes:

  * Common Lisp types
    The Common Lisp type system is a description language.
    L-APPLY is TYPEP, and L-LESSP is SUBTYPEP, although the
    SUBTYPEP relation is not as rich as the corresponding
    mathematical subtyping relation.

  * standard classes
    If you forget about slots and consing, you can treat standard
    classes as predicates over their objects.  This example is
    just a special case of the previous.

  * object identity
    The EQL specializers support a trivial description language,
    where all classes are singletons (except *L-TOP*, which is the type T).
    Here, L-APPLY is only EQL (apart from *L-TOP*) and so is L-LESSP.

  * Lisp structure patterns
    Someone from the functional programming community wanted to
    have specializers which were structure templates.  Often
    the pattern matching incorporates the binding of variables
    to matched substructures for later access.  This sort of thing
    is extremely useful.  (For example, Lisp compilers seem always
    to have some a destructuring case macro, with which they
    analyze program syntax.)

    Interestingly, L-LESSP is straightforward to define for
    destructuring patterns; it roughly consists of applying
    the second pattern to the first.

  * user-interface event patterns
    This is the application which I've been recently thinking about,
    which triggered this note.  User-interface modules often want to
    filter the events they see to some small set of "interesting"
    events.  This can be done with an event pattern.  Suppose a key
    event has three attributes: 1. key making the transition, 2. type of
    transition (e.g., up, down, click), and 3. modifier key state.
    Then an event pattern would specify a value for each attribute,
    or specify a wildcard of some sort.

    Clearly this is a description language.  (In fact, it is a
    product language, made from three languages, one for each
    attribute.)  It is easy to define L-APPLY and L-LESSP.

    If a module wanted to handle a class of events, it could define
    a method on an appropriate generic function, specialized to the
    desired event pattern.  The event-pattern meta-class would have
    the responsibility of building the glue logic to dispatch
    incoming events to the correct handler.  It's good to centralize
    this logic, because it can then be optimized more readily,
    and redundant tests eliminated.

    CLOS double dispatch would help here too:  Event handlers could be
    specialized both to consumer-object mixins and event types.

  * string regular expressions
    The theory of regular languages is well understood, and regular
    expressions are useful in a wide variety of settings.  A regular
    expression meta-class could be used to define complex string handling
    functions in a modular fashion.  Regular languages can be compared
    for specificity, so an L-LESSP predicate can be defined.  Also,
    efficient methods are known for matching several regular
    expressions at once to a single string; the meta-class would
    use these methods to build efficient dispatch ("glue") logic,
    as in the previous example.

  * knowledge base queries
    Pick your favorite database query language.  It certainly supports
    an L-APPLY operation, and probably also supports an L-LESSP.
    Now, with the right L-CLASS, you can define generic functions over
    database entries.  (It may be more useful to manipulate __sets__
    of entries, so U would then be a power set of some sort.
    This does not hinder the applicability of CLOS.)

I hope I have shown that (1) description languages are common and
useful, that (2) a general class of description languages are
amenable to treatment within the CLOS generic function framework,
and that (3) descriptions are very useful as defmethod
specializers.  The conclusion is that the designers of the
Meta-Object protocol should be sure to provide for arbitrary
description languages (of the L-APPLY/L-LESSP sort).

Finally, here are some smaller open questions about description
language classes, along with some possible answers:

  * How should the L-CLASS specify a linearization of a partially
    ordered set of applicable methods?

    [It is sometimes useful to signal an error if there is not a linear
    ordering available.  This could the default, with a hook for other
    more permissive behavior.]

  * What if the L-LESSP relation is not always effectively computable?
    (E.g., LISP:SUBTYPEP gives up sometimes.)

    [Allow the L-LESSP relation to give up, and treat this outcome like
    incomparability.  It should be possible to signal an error here,
    while still doing something permissive on true incomparability.]

  * If the L-term has "wildcards" in it, how should the L-CLASS mediate
    the binding of the corresponding U-object subparts to names for
    use in method bodies?

    [I believe the current protocol (e.g., DEFINE-METHOD-COMBINATION)
    provides enough hooks for this.  The hook which asks a meta-class
    for dispatch code should also accept LET-bindings, which would
    be constructed along with the dispatch code, and wrapped around
    the affected method body.]

  * What sort of syntax should L-CLASS specializers have?

    [The (EQL ...) syntax should be extended, I think.  The basic
    idea is that EQL is a meta-class name, and the arguments to
    it are handed to the meta-class constructor, which then
    builds the appropriate class object.  This is probably already
    the intention of the CLOS designers, but I want to affirm
    that choice.]

Let me close with a suggestive example:

	(DEFMETHOD EVAL ((X (FORM `(,F . ,A))))
	  (APPLY (EVAL `#',F) (MAPCAR #'EVAL A)))

	(DEFMETHOD EVAL ((X (FORM `(IF ,P ,A ,B))))
	  (IF (EVAL P) (EVAL A) (EVAL B)))

This example uses a hypthetical description language called FORM,
whose terms are backquoted constructors, interpreted in reverse.
(Or, if you like, declaratively as opposed to imperatively.)
Note that the specificity ordering ensures that IF forms will
not get passed to the first method, even though they match
its specializer.

				-- John


∂05-Aug-88  1833	Common-Lisp-Object-System-mailer 	Re: description language classes & the Meta-Object Protocol  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Aug 88  18:33:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 AUG 88 18:23:27 PDT
Date: Fri, 5 Aug 88 18:21 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: description language classes & the Meta-Object Protocol
To: John Rose <jrose@Sun.COM>
cc: common-lisp-object-system@sail.stanford.edu, CommonLoops.pa@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
In-Reply-To: <8808051925.AA05986@lukasiewicz.sun.com>
Message-ID: <19880806012130.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 5 Aug 88 12:25:14 PDT
    From: jrose@Sun.COM (John Rose)

    I'm going to describe a way I'd like to use the Meta-Object Protocol.
    Hopefully, readers of this list will either tell me why it's a
    misuse, or assure me that the Meta-Object Protocol will support
    what I have in mind.

Danny and I spent some time talking about this, and I plan to send a
message about this next week once I finish the current round of hacking.
-------

∂08-Aug-88  1020	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Aug 88  10:20:22 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 AUG 88 10:19:22 PDT
Date: Mon, 8 Aug 88 10:18 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: declare in with-slots
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>, Glenn Andrew Kramer
 <GAK@SPAR-20.SPAR.SLB.COM>, kempf@Sun.COM, David N Gray <Gray@DSG.csc.ti.com>
cc: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-3.text.newest
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
              <8808031410.AA03551@decwrl.dec.com>,
              <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
              <8808041525.AA20536@suntana.sun.com>,
              <2795711083-4281424@Kelvin>
Message-ID: <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


    Date: Wed, 3 Aug 88 07:10:42 PDT
    From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

    As to the suggested patch:  No, it won't really work.  Declare's are pretty
    much the province of special forms, and with-slots et al won't, in general, be
    able to parse the declare's, let alone interpret them correctly.  For example,
    a common extension to declare allows:

    (deftype t-terminated-list () '(or cons (member t)))

    (with-slots (x y z) <instance>
      (declare (t-terminated-list y))
      ...)

This declaration is clearly illegal according to CLtL.  Page 158,
paragraph 4 says:

  (<type> <var1> ...) is an abbreciation for (TYPE <type> <var1> ...)
  provided <type> is one of the types appearing in Table 4-1.

The reason this extension is a bad idea transcends with-slots and
friends of course.  No portable program analyzing program can analyze
code that uses this extension.

But, if a given implementation does in fact make this extension, it
could just smarten up its with-slots (or symbol-macrolet) implementation
to understand this case.

    While you're thinking about this, consider what would happen if Common Lisp
    were extended to allow:

    (with-slots (x y z) <instance>
      ...
      (locally (declare (fixnum y))
	...)
      ...)

    [CL doesn't currently allow this, but there's some sentiment to make this
    extension.]  Now with-slots would have to parse the entire body to get this
    right.

As would a large number of other forms that could be affected by this
change.  Putting the declare mechanism inside of symbol-macrolet, might
be percieved to "solve" this problem.  It seems to me that the real
problem with this case would be profusion of declaration hair though.
 
    What's the point of symbol-macrolet, then, if not to be the form which says
    "pretend foo is a variable, even though it's not"?  You're suggesting that only
    with-slots wants to play "let's pretend," and that there's some different roles
    that symbol-macrolet fills?  I doubt it...

This code from Jim Kempf shows how I was intending to have with-slots
expand, and shows clearly why I didn't think symbol-macrolet was the
place to support this.  Of course it is just as easy to put this in
symbol-macrolet as far as I am concerned.

    The expansion of with-slots would be something like:

	    (symbol-macrolet
	      ( (x (the fixnum (slot-value 'x obj)))
		(y (the fixnum (slot-value 'y obj)))
		(z (the fixnum (slot-value 'z obj)))
	      )
	      (locally
		<any other declarations>

		...
	      )
	    
-------

∂10-Aug-88  0952	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 10 Aug 88  09:51:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24519; Wed, 10 Aug 88 09:50:50 PDT
Date: Wed, 10 Aug 88 09:50:50 PDT
Message-Id: <8808101650.AA24519@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: Re: declare in with-slots

    From:	DECWRL::"Gregor.pa@Xerox.COM"  "8-Aug-88 1018 PDT"  8-AUG-1988 
    To:	Jeffrey Piazza <lisp::piazza>, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SL
    CC:	
    Subj:	Re: declare in with-slots

    Cc: common-lisp-object-system@sail.stanford.edu


	Date: Wed, 3 Aug 88 07:10:42 PDT
	From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

	...  For example,
	a common extension to declare allows:

	(deftype t-terminated-list () '(or cons (member t)))

	(with-slots (x y z) <instance>
	  (declare (t-terminated-list y))
	  ...)

    This declaration is clearly illegal according to CLtL.  

That's why I said "extension".

							    Page 158,
    paragraph 4 says:

      (<type> <var1> ...) is an abbreciation for (TYPE <type> <var1> ...)
      provided <type> is one of the types appearing in Table 4-1.

    The reason this extension is a bad idea transcends with-slots and
    friends of course.  No portable program analyzing program can analyze
    code that uses this extension.

I believe that's false.  A portable PAP can't use the declaration information,
that's all.  Of course, that might be a big lose, but declarations (except
SPECIAL) aren't supposed to affect semantics.  It would depend on what your
PAP was trying to find out.

    But, if a given implementation does in fact make this extension, it
    could just smarten up its with-slots (or symbol-macrolet) implementation
    to understand this case.

That's true.  I was thinking in terms of a portable implementation, which
would be impossible.  

	While you're thinking about this, consider what would happen if Common Lisp
	were extended to allow:

	(with-slots (x y z) <instance>
	  ...
	  (locally (declare (fixnum y))
	    ...)
	  ...)

	[CL doesn't currently allow this, but there's some sentiment to make this
	extension.]  Now with-slots would have to parse the entire body to get this
	right.

    As would a large number of other forms that could be affected by this
    change.  Putting the declare mechanism inside of symbol-macrolet, might
    be percieved to "solve" this problem.  It seems to me that the real
    problem with this case would be profusion of declaration hair though.



	What's the point of symbol-macrolet, then, if not to be the form which says
	"pretend foo is a variable, even though it's not"?  You're suggesting that only
	with-slots wants to play "let's pretend," and that there's some different roles
	that symbol-macrolet fills?  I doubt it...

    This code from Jim Kempf shows how I was intending to have with-slots
    expand, and shows clearly why I didn't think symbol-macrolet was the
    place to support this.  

Just because the expansion is relatively simple doesn't, of course, mean that
it's really the "right" thing to do.

What if I, a random user, wish to write e.g. my own "with-file-attributes"
macro, that lets me access things like the read and write dates for a file as
symbol-macrolet "variables".  Not being an implementor, I don't have access to
the system declaration-parsing stuff, so I can't support declarations in the
way you're proposing for with-slots and with-accessors.  I cry "no fair".

I am aware of no other macro which has to parse declarations -- they just get
pushed off to some special form or other.  I think that, for what you're
trying to do, you have to make symbol-macrolet be a special form, and do
declaration processing there.

/JEP

PS on a slight tangent:  What's the meaning of:


(with-slots (x y z) <instance>
  ...
  (locally (declare (special y))
    ...y...)
  ...)

Is the y inside the locally the special variable or the slot?  I believe the
current definition would make it the slot.  I also believe that's anomolous.

∂11-Aug-88  0810	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Aug 88  08:10:33 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA24336; Thu, 11 Aug 88 08:07:26 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA02372; Thu, 11 Aug 88 08:07:44 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA11766; Thu, 11 Aug 88 08:06:24 PDT
Message-Id: <8808111506.AA11766@suntana.sun.com>
To: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Cc: common-lisp-object-system@sail.stanford.edu
Subject: Re: declare in with-slots 
In-Reply-To: Your message of Wed, 10 Aug 88 09:50:50 -0700.
             <8808101650.AA24519@decwrl.dec.com> 
Date: Thu, 11 Aug 88 08:06:21 -0700
From: kempf@Sun.COM


>Just because the expansion is relatively simple doesn't, of course, mean that
>it's really the "right" thing to do.

Are we talking religion or engineering? If the former, then count me in
as a lang-nostic. :-)

Seriously, there is rarely ever a single "right" way to engineer anything.
There are usually pros and cons on both sides. The "pro" of this solution
is that it is simple, the "con" is that it treats type declarations for
pseudo variables differently from those for lexical variables or other
declarations.

>What if I, a random user, wish to write e.g. my own "with-file-attributes"
>macro, that lets me access things like the read and write dates for a file as
>symbol-macrolet "variables".  Not being an implementor, I don't have access to
>the system declaration-parsing stuff, so I can't support declarations in the
>way you're proposing for with-slots and with-accessors.  I cry "no fair".

This is a valid point, but I wonder if it isn't in the same category as
generalized code walkers.

>I am aware of no other macro which has to parse declarations -- they just get
>pushed off to some special form or other.  I think that, for what you're
>trying to do, you have to make symbol-macrolet be a special form, and do
>declaration processing there.

Two points here. First, though I've got no objection either way on making
symbol-macrolet be a special form, the goal of Common Lisp was (and I
think still is) to limit the number of special forms. Second, I think
it would be a mistake to confuse general declaration parsing with parsing
of declarations for pseudovariables. Symbol-macrolet will have to do declaration
parsing for pseudovariable declarations in any event. While there are no
macros which currently do declaration parsing, there are plenty which
do parsing (like defstruct). 

As a point of reference, HP Lisp had a special form called let-pseudo
whose semantics were identical to symbol-macrolet, and were used for
a similar purpose, namely to provide lexical scopes in which 
slot names could be used as pseudovariables for slot access. Type
declarations included in the class definition were included in 
the substitution form for the pseudovariable. I don't recall if 
declarations for pseudovariables were parsed (perhaps someone still
having access to HP Lisp could check), but I wouldn't be suprised
if they were.

		jak



∂11-Aug-88  1021	Common-Lisp-Object-System-mailer 	Re: declare in with-slots 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 11 Aug 88  10:21:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA08505; Thu, 11 Aug 88 10:20:18 PDT
Date: Thu, 11 Aug 88 10:20:18 PDT
Message-Id: <8808111720.AA08505@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: kempf@sun.com
Subject: Re: declare in with-slots 

    From:	DECWRL::"kempf@Sun.COM"  "11-Aug-88 0806 PDT" 11-AUG-1988 11:09:28.36

    >Just because the expansion is relatively simple doesn't, of course, mean that
    >it's really the "right" thing to do.

    Are we talking religion or engineering? If the former, then count me in
    as a lang-nostic. :-)

Sometimes it's hard to tell the difference.

    Seriously, there is rarely ever a single "right" way to engineer anything.
    There are usually pros and cons on both sides. The "pro" of this solution
    is that it is simple, the "con" is that it treats type declarations for
    pseudo variables differently from those for lexical variables or other
    declarations.

I tend to believe that in engineering as elsewhere, "separate but
equal" facilities are never really "equal".  Declarations are
ultimately handled by the interpreter/compiler (even if you change a
"declare" into a "the"), and I anticipate lossage if macros try to
intercept them beforehand.  I'm just not confident that declarations
are understood well enough for this to be well-behaved.

    >What if I, a random user, wish to write e.g. my own "with-file-attributes"
    >macro, that lets me access things like the read and write dates for a file as
    >symbol-macrolet "variables".  Not being an implementor, I don't have access to
    >the system declaration-parsing stuff, so I can't support declarations in the
    >way you're proposing for with-slots and with-accessors.  I cry "no fair".

    This is a valid point, but I wonder if it isn't in the same category as
    generalized code walkers.

When I write a generalized code walker, I expect this level of hair,
while with-file-attributes seems like it should be simple to write.

    >I am aware of no other macro which has to parse declarations -- they just get
    >pushed off to some special form or other.  I think that, for what you're
    >trying to do, you have to make symbol-macrolet be a special form, and do
    >declaration processing there.

    Two points here. First, though I've got no objection either way on making
    symbol-macrolet be a special form, the goal of Common Lisp was (and I
    think still is) to limit the number of special forms.  

Well, we could give up, say, GO, and that would make for fewer special
forms :-).  I think that "pseudovariables" represent a real change in
the language semantics, and require a special form.  (As you probably
know, my personal preference would be to remove symbol-macrolet
altogether, rather than introduce a new special form.  But if you keep
the feature, I think you have to pay the price of a special form to
realize it.)

							   Second, I think
    it would be a mistake to confuse general declaration parsing with parsing
    of declarations for pseudovariables. Symbol-macrolet will have to do declaration
    parsing for pseudovariable declarations in any event. 

If symbol-macrolet were a special form, it would be the interpreter/
compiler that parsed out the declarations, just as it does for real
variables.  I think it would be a mistake NOT to unify declarations
for pseudovariables with declarations for real variables.

							  While there are no
    macros which currently do declaration parsing, there are plenty which
    do parsing (like defstruct). 

Defstruct gets to define the syntax it's parsing, which makes it
altogether different.  We're talking about having with-slots "skim"
some declaration text, extract the bits it thinks it's interested in,
and then put back what's left, so the interpreter or compiler can see
it.

    As a point of reference, HP Lisp had a special form called let-pseudo
    whose semantics were identical to symbol-macrolet, and were used for
    a similar purpose, namely to provide lexical scopes in which 
    slot names could be used as pseudovariables for slot access. Type
    declarations included in the class definition were included in 
    the substitution form for the pseudovariable. I don't recall if 
    declarations for pseudovariables were parsed (perhaps someone still
    having access to HP Lisp could check), but I wouldn't be suprised
    if they were.

If let-pseudo is really symbol-macrolet in disguise, then it's not
exactly independent evidence.  Also, if let-pseudo is/was a special
form, then it doesn't really apply to the question of macros that
parse declarations.  You can put all kinds of declarations in a
special form; it won't make me unhappy.

/JEP

∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  20:04:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
    Barry Margolin <barmar@Think.COM>, cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
    Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
             <8806222146.AA21530@decwrl.dec.com>,
             <8806281758.AA10391@decwrl.dec.com>,
             <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <8806291818.AA11107@mist.UUCP>,
             <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
             <19880729021542.8.BARMAR@OCCAM.THINK.COM>,
             <8807292109.AA03546@decwrl.dec.com>,
             <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand.  10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.

I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.

∂09-Sep-88  1203	RPG 	first part of mop   
 ∂09-Sep-88  1031	dussud@lucid.com 	first part of mop
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Sep 88  10:31:08 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate.lucid.com id AA00784g; Fri, 9 Sep 88 09:29:19 PST
Received: by kent-state id AA07276g; Fri, 9 Sep 88 10:28:02 PDT
Date: Fri, 9 Sep 88 10:28:02 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809091728.AA07276@kent-state>
To: Gregor.pa@Xerox.COM
Cc: Moon@Stony-Brook.SCRC.Symbolics.com, RPG@Sail.Stanford.edu,
        Bobrow.PA@Xerox.COM, dussud@lucid.com
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 6 Sep 88 22:31 PDT <19880907053113.0.GREGOR@PORTNOY.parc.xerox.com>
Subject: first part of mop


I find the general contents quite good. I have few comments:

Do you intent to keep the description of the metaobjects like this, and then
present the accessors, in alphabetic order, one per page, or do you intend to
list them right were you describe the metaobjects?
Personally, I lean toward the latter approach:
-All of the accessors have several properties in common: The user cannot alter
the information returned by the accessors (lists of objects). The users cannot
rely on when and how may times, the system will call these accessors, and so
on.
-Their semantics are trivial. they just return some data from the objects. We
don't need a whole page each time to say that.

I was surprised by the principle 8 (pg 3-8). Since we say that slots for these
objects are internal business, I don't see why we should restrict the domain
of their names. The user shouldn't even try to find out their names.

I agree with the principles exposed here. Maybe you should emphasize the
distinction between the protocol specification, and the standard
implementation of the metaobject protocol, by saying that they will belong in
different parts of chapter 3.

Patrick.

∂10-Sep-88  1150	RPG 	Re: first part of mop    
 ∂09-Sep-88  1626	Gregor.pa@Xerox.COM 	Re: first part of mop   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Sep 88  16:26:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 SEP 88 15:37:34 PDT
Date: Fri, 9 Sep 88 15:37 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: first part of mop
To: Patrick Dussud <dussud@lucid.com>
cc: Moon@Stony-Brook.SCRC.Symbolics.com, RPG@Sail.Stanford.edu,
 Bobrow.PA@Xerox.COM
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809091728.AA07276@kent-state>
Message-ID: <19880909223720.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 9 Sep 88 10:28:02 PDT
    From: Patrick Dussud <dussud@lucid.com>

    I find the general contents quite good. I have few comments:

Thank you, I am glad to hear it.

    Do you intent to keep the description of the metaobjects like this, and then
    present the accessors, in alphabetic order, one per page, or do you intend to
    list them right were you describe the metaobjects?
    Personally, I lean toward the latter approach:

    -All of the accessors have several properties in common: The user cannot alter
    the information returned by the accessors (lists of objects). The users cannot
    rely on when and how may times, the system will call these accessors, and so
    on.
    -Their semantics are trivial. they just return some data from the objects. We
    don't need a whole page each time to say that.

I plan to do something like this, and for precisely the reasons you
mention.  I plan to put the protocol specification and the standard
protocol implementation specification in different places.  I plan to
group related methods like these to make it simple to talk about
properties they have in common.  For example, there is a principle that
says (something like) you can't override less than all of a set of
methods which share memory.

I do plan to leave the overview stuff where it is up front.  I realize
that this is just a specification, but I feel that the 2.5 pages it
takes up are worth it to provide that kind of summary of the
interconnections among metaobjects.

    I was surprised by the principle 8 (pg 3-8). Since we say that slots for these
    objects are internal business, I don't see why we should restrict the domain
    of their names. The user shouldn't even try to find out their names.

This principle may need debugging, but its reason for existing is to let
me know that the following code is sure to work in any implementation:

(in-package 'user)

(defclass foo (standard-class) (foo bar baz))

A reasonable question to ask is should we also make this code legal:

(in-package 'user)

(defclass bar (standard-class) (list car +))

    I agree with the principles exposed here. Maybe you should emphasize the
    distinction between the protocol specification, and the standard
    implementation of the metaobject protocol, by saying that they will belong in
    different parts of chapter 3.

Yes, this is what I plan.
-------

∂12-Sep-88  1102	Common-Lisp-Object-System-mailer 	Fairfax Meeting 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 12 Sep 88  11:01:26 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA10872; Mon, 12 Sep 88 10:58:11 PDT
Received: from suntana.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15636; Mon, 12 Sep 88 11:01:05 PDT
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
	id AA00397; Mon, 12 Sep 88 11:00:54 PDT
Message-Id: <8809121800.AA00397@suntana.sun.com>
To: common-lisp-object-system@sail.stanford.edu
Subject: Fairfax Meeting
Date: Mon, 12 Sep 88 11:00:50 PDT
From: kempf@Sun.COM



	Is there any need or plan for a subcommittee meeting?

		jak

∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:47:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458005; Mon 12-Sep-88 20:43:49 EDT
Date: Mon, 12 Sep 88 20:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Gregor.pa@Xerox.COM, David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <edsel!dussud@labrea.stanford.edu>,
    kempf@Sun.COM, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>, common-lisp-object-system@SAIL.STANFORD.EDU,
    Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
             <2795614606-3753982@Kelvin>,
             <8808031719.AA12130@rainbow-warrior.lucid.com>,
             <8808031847.AA18770@suntana.sun.com>,
             <2795636967-5097451@Kelvin>,
             <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
             <8808041525.AA20536@suntana.sun.com>,
             <2795711083-4281424@Kelvin>,
             <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>,
             <8808111506.AA11766@suntana.sun.com>
Message-ID: <19880913004248.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Issue:         SYMBOL-MACROLET-DECLARE

References:    SYMBOL-MACROLET (88-002R page 2-81)
               WITH-ACCESSORS (88-002R page 2-88)
               WITH-SLOTS (88-002R page 2-92)

Category:      ADDITION

Edit history:  Version 1, 12-Sep-88, Moon

Problem description:

It would be both natural and nice to be able to write

  (with-slots (rho theta) point
    (declare (single-float rho theta))
    ...computation...)

Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
	  
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS.  Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet.  A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.

Test Cases/Examples:

See problem description.

Rationale:

If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations.  When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration.  However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.

Current practice:

SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.

Cost to Implementors:

Less than one man-hour.

Cost to Users:

None.

Cost of non-adoption:

Minor wart in the language.

Benefits:

More consistent language definition.

Esthetics:

More consistent language definition.

Discussion:

None.

∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:08:47 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24481; Tue, 13 Sep 88 07:06:10 PDT
Date: Tue, 13 Sep 88 07:06:10 PDT
Message-Id: <8809131406.AA24481@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)

This seems like a reasonable proposal and does make SYMBOL-MACROLET more
consistent with LET.

This may be a separate issue, but somewhere we should nail down the
interpretation of e.g.

	(symbol-macrolet ((foo bar))
	  ...
	  (locally (declare (special foo))
	    ...foo...))

As currently specified, only a new binding for FOO can turn off its
interpretation as a symbol macro.  I'd like to see some language that said that
a SPECIAL declaration also shadows the symbol macro scope.

The limit case, which your proposal makes "an error", might then reasonably
have a null semantics:

	(symbol-macrolet ((foo bar))
	  (declare (special foo))
	  ...)

might be interpreted as

	(locally (declare (special foo))
	  ...)

I don't have strong feelings one way or the other about this part--it doesn't
seem possible to bring SYMBOL-MACROLET into complete consistency with LET here.

/JEP

∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  11:45:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00217g; Tue, 13 Sep 88 10:43:38 PST
Received: by rainbow-warrior id AA03013g; Tue, 13 Sep 88 11:41:59 PDT
Date: Tue, 13 Sep 88 11:41:59 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809131841.AA03013@rainbow-warrior>
To: piazza%lisp.DEC@decwrl.dec.com
Cc: Moon@stony-brook.scrc.symbolics.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Jeffrey Piazza's message of Tue, 13 Sep 88 07:06:10 PDT <8809131406.AA24481@decwrl.dec.com>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)

   Date: Tue, 13 Sep 88 07:06:10 PDT
   From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

   This seems like a reasonable proposal and does make SYMBOL-MACROLET more
   consistent with LET.

   This may be a separate issue, but somewhere we should nail down the
   interpretation of e.g.

	   (symbol-macrolet ((foo bar))
	     ...
	     (locally (declare (special foo))
	       ...foo...))

   As currently specified, only a new binding for FOO can turn off its
   interpretation as a symbol macro.  I'd like to see some language that said that
   a SPECIAL declaration also shadows the symbol macro scope.

That seems reasonable.

   The limit case, which your proposal makes "an error", might then reasonably
   have a null semantics:

	   (symbol-macrolet ((foo bar))
	     (declare (special foo))
	     ...)

   might be interpreted as

	   (locally (declare (special foo))
	     ...)

This would be a very bad idea, it would be very inconsistent with LET, and
would introduce a bizarre semantics: Throw away what I just said in the
binding list. I think that it should be an error.

Patrick.




∂14-Sep-88  1817	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  18:17:25 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA22171; Wed, 14 Sep 88 18:13:51 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA05670; Wed, 14 Sep 88 18:16:43 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00310; Wed, 14 Sep 88 17:10:07 PDT
Date: Wed, 14 Sep 88 17:10:07 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8809150010.AA00310@lukasiewicz.sun.com>
To: halasz%sw.MCC.COM@MCC.COM
Cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: Frank Halasz's message of Wed, 14 Sep 88 18:48:41 CDT <8809142348.AA11205@oryan.sw.mcc.com>
Subject:  call-next-method and arguments to :before and :after methods

[In response to Frank Halasz's query, I sent him a pointer to the definition of
standard method combination in the manual pages for DEFINE-METHOD-COMBINATION.
Here's the subsequent conversation.  I think the whole exchange may
point up an omission in the CLOS documentation.]

   Date: Wed, 14 Sep 88 18:48:41 CDT
   From: Frank Halasz <halasz%sw.MCC.COM@MCC.COM>

   Thanks, the code under DEFINE-METHOD-COMBINATION helps.  But its still seems
   a bit ambiguous due to the interpretation of the make-method clause
   in call-method.  Specifically, call-method passes on the "arguments that
   were supplied to the effective method form containing the invocation
   of call-method."  The effective method form in the example code boils
   down to the following:

   `(call-method ,(first around)
		 (,@(rest around)
		  (make-method 
		    (multiple-value-prog1
		      (progn ,@(call-methods before)
			     (call-method ,(first primary)
					  ,(rest primary)))
		      ,@(call-methods (reverse after))))))

   The issue is whether the call-method invocations inside the make-method
   are part of the (outer) effective method form.  Alternatively, make-method
   could be considered as bounding a "new" inner effective method form.
   The current PCL effectively takes the latter alternative.  It seems to
   me that the spec takes the former reading, in which case :before and :after
   methods ought to get the arguments passed down to the original call to
   the genric function.

   -- Frank

The "alternative" that CALL-METHODs are lexically scoped to the
innermost MAKE-METHOD seems to be the only viable alternative.
If, as you suggest, scoping were to the outer effective method
body, there would be in fact no way to deliver arguments as adjusted
by CALL-NEXT-METHOD to any method other than those created
implicitly by the system; any method you make with MAKE-METHOD
would be powerless to access the adjusted arguments, because
when it tried to use CALL-METHOD (as it must), the adjusted arguments
would be rebound to their original values.  So what you're suggesting
would probably be a serious design flaw.

While your suggested semantics would be unable to simulate the
current (and historically correct; see next paragraph) semantics,
the reverse is not the case.  In order to simulate your suggested
semantics, say for a special-purpose method combination type,
FLET bindings could be used to capture code at the outer scoping level,
which could then be invoked from a MAKE-METHOD at any level:
	`(flet ((do-before-around ()
	          ,@(call-methods before-around)))
	   (call-method ,(first around)
			(,@(rest around)
			 (make-method
			   (multiple-value-prog1
			     (progn (do-before-around)
				    ...))))))

By the way, I find it totally natural that :AROUND methods surround
primary, :BEFORE, and :AFTER methods, and are thus able to adjust
their actual arguments.  This is the way it worked in Flavors,
which is where this method combination stuff comes from, and
I've never heard anyone question it before.  The grouping is this:
	AROUND( BEFORE PRIMARY AFTER )
rather than this:
	BEFORE AROUND( PRIMARY ) AFTER

(Now, I don't find CLOS standard method combination as a whole very
natural, for larger reasons, and I wish that the Flavors influence
were less strong here, but that's a separate issue.)

It is perhaps a documentation bug that the scoping of CALL-METHOD
is not better spelled out.  Does it really say "arguments that were
supplied to the effective method form containing the invocation
of call-method"?  I can't find any statement one way or the other in my
version of the spec, which is an old version.  I would have expected
words like "innermost effective method or MAKE-METHOD form" instead of
"effective method form".

(This bug report is the reason for the CC to the Powers That Be.)

				-- John

∂15-Sep-88  1304	Common-Lisp-Object-System-mailer 	call-next-method and arguments to :before and :after methods 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Sep 88  13:03:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459910; Thu 15-Sep-88 16:00:52 EDT
Date: Thu, 15 Sep 88 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: call-next-method and arguments to :before and :after methods
To: John Rose <jrose@Sun.COM>, halasz%sw.MCC.COM@MCC.COM
cc: common-lisp-object-system@sail.stanford.edu
In-Reply-To: <8809150010.AA00310@lukasiewicz.sun.com>
Message-ID: <19880915200041.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

It's true that when call-next-method was given the ability to change
the arguments, not all of the places in the CLOS specification that
should have been updated were.  Thus some pages don't discuss what
happens in this case.  Page 2-11 of 88-002R (describing call-method)
ought to make it clear that when an invocation of call-method is
nested inside an invocation of make-method, the arguments passed
along by call-method are the arguments that were supplied to the
make-method, not the arguments supplied to the original generic
function call.  Thus call-next-method in a :around method can
alter the arguments seen by :before and :after methods.

I'll send something about this to the Cleanup committee, after
waiting a few days for comments.

∂15-Sep-88  1331	Common-Lisp-Object-System-mailer 	Re: call-next-method and arguments to :before and :after methods  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88  13:31:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 13:24:01 PDT
Date: 15 Sep 88 13:23 PDT
From: masinter.pa@Xerox.COM
Subject: Re: call-next-method and arguments to :before and :after methods
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Thu, 15 Sep 88 16:00 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: John Rose <jrose@Sun.COM>, halasz%sw.MCC.COM@MCC.COM,
 common-lisp-object-system@sail.stanford.edu
Message-ID: <880915-132401-3007@Xerox>

If there are editorial problems in the CLOS specification where some items are
only explained in one place and not in others, I don't think we need to have
full-fledged cleanup issues associated with them. There's some judgement
involved, but the primary motivation for the rather extensive debates we have on
cl-cleanup is to make sure that the issues of costs and benefits-- especially
for incompatible changes-- are fully addressed.

So: I think symbol-macrolet deserves to be debated as a "cleanup", but  if there
is general agreement of the CLOS committee that the document does not reflect
the intent, I think you should just handle them as editorial amendments.


∂20-Sep-88  1817	Common-Lisp-Object-System-mailer 	Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88  18:17:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:02:57 PDT
Date: 20 Sep 88 18:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
In-reply-to: Patrick Dussud <dussud@lucid.com>'s message of Tue, 13 Sep 88
 11:41:59 PDT
To: Patrick Dussud <dussud@lucid.com>
cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
 Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-180257-5257@Xerox>

We need to get this cleaned up in time to present to X3J13. 

I think it is at least consistent with LET semantics to say that 

(LOCALLY (DECLARE (SPECIAL X)) ...) introduces a new scope for X. Its consistent
with
(LET((X 4)) (DECLARE (SPECIAL X))
(LET ((X 3))
 (LOCALLY (DECLARE (SPECIAL X)) X)))

returning 4.

I.e., add to the proposal something like:


Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
introduces a new scope for the variable(s) declared special, and will override
within its scope any SYMBOL-MACROLET.

∂20-Sep-88  2008	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88  20:08:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05077g; Tue, 20 Sep 88 19:06:13 PST
Received: by rainbow-warrior id AA19120g; Tue, 20 Sep 88 20:04:34 PDT
Date: Tue, 20 Sep 88 20:04:34 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809210304.AA19120@rainbow-warrior>
To: masinter.pa@Xerox.COM
Cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 20 Sep 88 18:02 PDT <880920-180257-5257@Xerox>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)

   Date: 20 Sep 88 18:02 PDT
   From: masinter.pa@Xerox.COM

   We need to get this cleaned up in time to present to X3J13. 

   Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
   introduces a new scope for the variable(s) declared special, and will override
   within its scope any SYMBOL-MACROLET.

I agree with this. We should also specify that  SPECIAL  shouldn't be used in
the declaration part of a symbol-macrolet. Locally special declaration are
fine. 
Patrick.

∂21-Sep-88  1423	Common-Lisp-Object-System-mailer 	metaobject protocol (description languages)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88  14:23:13 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA06488; Wed, 21 Sep 88 14:18:19 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA07789; Wed, 21 Sep 88 14:20:58 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA15464; Wed, 21 Sep 88 13:14:22 PDT
Date: Wed, 21 Sep 88 13:14:22 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8809212014.AA15464@lukasiewicz.sun.com>
To: K311770@AEARN.BITNET
To: Gregor.pa@Xerox.COM, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Hubert Hofbauer's message of Wed, 21 Sep 88 15:29:23 EDT <880921-091549-596@Xerox>
Subject: metaobject protocol (description languages)

   At RISC Linz we are currently evaluating PCL as a basis for our symbolic
   computation library. An important issue in this field are parameterized types
   - families of classes - such as zmod N, polynomial over A-FIELD in VARS,
   matrix DIMS of DOMAIN,... , where N, A-FIELD, VARS, DIMS, and DOMAIN are
   parameters for type zmod, polynomial, and matrix.
   We would like something like (DEFCLASS (ZMOD N) ...) and
   (DEFMETHOD xxx ((Z (ZMOD N))... )... ).

Given the ability to make reasonably general user-definable
specializers, you could fake parametrized types, by putting
the parametrization info into a slot, and defining a specializer
type which dispatched on that slot's value.  Something like this:
	(DEFCLASS ZMOD ((N) ...) ...)
	(DEFDESCRIPTION ZMOD
	    ((N :KEY #'(LAMBDA (X) (SLOT-VALUE X 'N))))
	  (:SUPER (ZMOD)))
	(DEFMETHOD # ((Z (ZMOD N)) ...) ...)

The fictitious DEFDESCRIPTION form would give meaning to specializers
of the form (ZMOD #).  The effect would be to enrich the standard
"description language" of specializers, which consists only of
class names and EQL constructs.  A certain amount of structure
is needed to relate new descriptions to the existing ones;
this has been discussed in previous messages from me.

I believe that many uses of the meta class protocol will center
around the extension of the specializer syntax and semantics
(hence, of the generic function dispatch mechanisms), rather
than around finding new ways to implement slotted structures.

				-- John

∂05-Oct-88  1242	CL-Compiler-mailer 	Issue: DEFINE-OPTIMIZER  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88  12:41:50 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA02898; Wed, 5 Oct 88 12:35:41 PDT
Received: from lukasiewicz.sun.com by snail.sun.com (4.0/SMI-4.0)
	id AA15109; Wed, 5 Oct 88 12:38:05 PDT
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA09635; Wed, 5 Oct 88 11:31:32 PDT
Date: Wed, 5 Oct 88 11:31:32 PDT
From: jrose@Sun.COM (John Rose)
Message-Id: <8810051831.AA09635@lukasiewicz.sun.com>
To: jlm@lucid.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson%mist@MULTIMAX.ARPA
Cc: sandra%defun@cs.utah.edu
Cc: CL-Compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 30 Sep 88 12:07:09 PDT <8809301907.AA01035@bhopal>
Subject: Issue: DEFINE-OPTIMIZER 

   Date: Wed, 28 Sep 88 15:32:23 PDT
   From: Jim McDonald <jlm@lucid.com>

   I would prefer to see a rule-based approach, at least as the normal
   way of declaring optimizations.  A more programmable approach would
   be used only when the rule processor is inadequate.

   E.g., I find it much easier to read rules of the form:

    ((<arg-type>*) <result-type> <rewrite-pattern>)
    or
    ((<arg-type>*) (<result-type>*) <rewrite-pattern>)

  ....
Hear, hear.  (See below.)


   Date: Wed, 28 Sep 88 17:07:21 MDT
   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

   ...while I think that just about all
   compilers do some kind of pattern-matching transformations, everybody
   seems to use a different technique and syntax for specifying them, and
   we'd probably get into religious wars if we tried to standardize one
   or another of them.  (I know of at least a half-dozen different ones
   that have been used in the various compilers developed here at Utah
   within the past 2 or 3 years!)
Perhaps CLOS can eventually supply a partial consensus on how to organize
these things.  (See below.)

   Date: Thu, 29 Sep 88 11:20 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

   I think the way Symbolics does its optimizers (I haven't looked recently) is
   to allow multiple optimizers on a function and to give each a name, so that
   you can selectively redefine each. In effect, it defines

    INTERNAL-DEFINE-OPTIMIZER function optimizer-name bvl &BODY forms

   so that (effectively) you could define DEFINE-OPTIMIZER as 

    (DEFMACRO DEFINE-OPTIMIZER (NAME BVL &BODY FORMS)
      `(INTERNAL-DEFINE-OPTIMIZER ,NAME ANSI-CL-INTERFACE ,BVL ,@FORMS))

  ....
CLOS has a mechanism for named function parts; see below.


   Date: Fri, 30 Sep 88 12:07:09 PDT
   From: Jim McDonald <jlm@lucid.com>
  ...

   I should note that Lucid's compiler-macro facility allows one to
   define a symbol to be treated as a function at eval-time but a macro 
   at compile-time.  One obvious use of compiler-macros is to implement
   optimizers.  The drawback is the one I alluded to earlier -- there is
   just one compiler-macro for a symbol, so you run the risk of a
   brain-dead dotimes if you try to optimize it as in my example above.

   (I'd be tempted to suggest a compiler-macro-time analog to defadvice,
    but that seems too hairy, too dependent on the whole idea of
    compiler-macros, and too fraught with the dangers I railed against
    earlier.)
Yes it's hairy, but maybe we can lean on CLOS.

  ....

Attaching multiple transformation rules on one function seems superior
to having to express all the logic in a monolithic optimizer function.
After all, some Lisp functions will be complex enough to admit several
independent optimization strategies, each encodable by a different rule.
Perhaps two vendors or programmers want to add strategies to the same
function; it's unclear how to do this through a monolithic optimizer.

One might object that only the function's author should get to optimize
it, but that's not the case when the function is well-known and the
occasion for optimizing it arises when some specialized __argument__
appears for it.  E.g., (SQRT (MY-EXPONENTIAL X)) => (MY-EXPONENTIAL (/ X
2)), or perhaps something like (SEARCH WORD (MY-INDEXED-STRING X)) =>
(MY-INDEXED-SEARCH WORD X).

Even if it's agreed that we want multiple optimization rules on a single
function, there is still the problem of (1) arranging for the separate
compilation and eventual combination of the rules, and (2) specifying
the language(s) used to write the  patterns which guard the rules.

I believe CLOS supplies excellent answers to (1), and eventually will
enable an answer to (2).

It seems to me that, in the interests of economy, whenever there is a
situation in Common Lisp where multiple, separately compilable program
fragments are being combined into single functions (e.g., DEFADVICE,
optimizer rules), that service should be if at all possible supplied
by CLOS.  Using CLOS has a number of advantages:

 * Implementors have less work, since they use CLOS method combination
   machinery.  In some cases, they may only need to write a
   DEFINE-METHOD-COMBINATION which organizes the program fragments
   the way they want.

 * Users have a standard interface for defining, undefining, and
   querying for program fragments.

 * Any CLOS program management tools (e.g., browsers) are immediately
   applicable.

To summarize, you get the usual advantages of integration.

Classes per se needn't enter the picture at all.  I'm thinking of
something like this, for starters:

	(defmethod compiler:transform sqrt-exp ((fn (eql 'sqrt)) &rest args)
	  (backquote-case args
	    (`((my-exp ,x)) `(my-exp (/ ,x 2)))
	    (otherwise (call-next-method))))

(In place of the hypothetical BACKQUOTE-CASE, put your own favorite
pattern matcher.)  The key is using the method qualifier syntax
(SQRT-EXP, here) for differentiating fragments of code.  If the CLOS
specializer syntax is usable ((EQL 'SQRT), here), that's great, but
unspecialized methods are perfectly valid too.

[Parenthetical Note:  To implement advice this way, you'd probably want
 to introduce a new function specifier syntax, analogous (SETF FOO):
	(defmethod (advise foo) :before ensure-open-foo-files (&rest ignore)
	  (declare (ignore ignore))
	  (unless (foo-files-open-p) (open-foo-files)))
 Note that use of two method qualifiers.  That's OK, and the abstraction's
 DEFINE-METHOD-COMBINATION declaration gets to assign the appropriate
 meaning to them.]

That should show how CLOS addresses problem (1), of managing code
fragments.

Problem (2), the construction of rule guard patterns, may be partially
addressible in CLOS, some day.  The key is realizing that your favorite
pattern language for Lisp forms probably has enough structure to impose a
type/subtype structure on the universe of Lisp forms.  In other words,
it makes sense to pretend that patterns in your language (e.g.,
`((my-exp ,x)) above) define form types, and that there is an inclusion
structure on these types, with less specific patterns being supertypes.
(When talking about these issues to the CLOS people, I have referred to
such a system of patterns or predicates as a "description language".)

If CLOS provides enough extensibility of specializer syntax (and that's
a big if, actually), it will be possible to express optimizer rules
even more cleanly, using CLOS.  Here's a final example, in which
a form-discriminating specializer is used (with a syntax pulled
out of a hat, I admit):

	(defmethod compiler:transform ((:form `(sqrt (my-exp ,x))))
	  `(my-exp (/ ,x 2)))

Note that since the specializers suffice to differentiate the rules,
there is less need for qualifiers (e.g., the symbol SQRT-EXP above).

The CLOS spec. does not discuss extensibility of specializers, yet.
For this, we await the famous but mysterious third chapter of the spec,
the Meta-Object Protocol.

By the way, a useful second argument to COMPILER:OPTIMIZE
would be an environment, to allow for type checking or macroexpansion.

I've used list structure patterns in the examples above, but I
could equally well have used patterns which discriminated things
like declared type, if I understood enough about Lisp compiler
type inference to construct a plausible example.

As Sandra says, there are any number of pattern languages out there.
I'm certainly not suggesting it's easy to settle on one, but I am
saying that using CLOS would help us settle some of the simpler issues
(like separate compilation of rules), allowing us to devote more energy
to the hard ones (like pattern languages).  In fact, I don't see why
several pattern languages couldn't be used in the same Lisp.  After all,
EQL and class specializers co-exist now, and they could be viewed as two
different languages.

The bottom line is that CLOS has a lot of services to offer, and Common
Lisp should take advantage of them where possible.

				-- John

∂05-Oct-88  1503	Common-Lisp-Object-System-mailer 	Q about CLOS    
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88  15:03:16 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59461; 5 Oct 88 17:50:52 EDT
Date: Wed, 5 Oct 88 17:52 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Q about CLOS
To: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <19881005215228.4.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

None of the doc I've scrounged for CLOS answers this simple question, so
anyone who can enlighten me, thanks...

is EVAL a generic function (message)?

is APPLY?

Thanks,
----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂05-Oct-88  1934	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88  19:34:00 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59502; 5 Oct 88 22:21:29 EDT
Date: Wed, 5 Oct 88 22:23 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881005-152958-1624@Xerox>
Message-ID: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

I'd like to propose an alternative (or rather elaboration) to
EVAL-OTHER:SELF-EVALUATE,  currently...

    Proposal (EVAL-OTHER:SELF-EVALUATE):

      Standard data types (those mentioned by CLtL) other than those for which
      a more explicit evaluation rule exists would be defined to self-evaluate.
      Such data types include, for example, structures, arrays, vectors, and
      pathnames.

      Structure types defined by users using DEFSTRUCT should also self-evaluate
      unless an explicit implementation type for the structure is given in the
      DEFSTRUCT, in which case the rule for evaluation of that type should be
      used. (This is important in the case of type LIST.)

I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
explicitly specifies the eval behavior.

Rational:

When using lisp to build an embedded language, one can already define via a
DEFSTRUCT option what the printer for the object should be. One can also,
via character macros define a specific parse behavior. One cannot, however,
currently define an EVAL behavior.  For example, I can define #\[ and #\] to
denote the beginning and end of information for consing a structure FOO via
character macros which will print the same way.

e.g. [A FOO] may really be internally #S(FOO SLOT1: A SLOT2: FOO SLOT3: NIL)

what I may want to define is that (cons [A FOO] [B FOO]) return (A B)
because the EVAL option on foo returned the value of SLOT1.

In general, one could define that instances and structure objects (the
latter are probably instances given CLOS) all handle an EVAL message which
the user can use to explicitly define the behavior. The default handler
returns the object itself, which is compatible with the
EVAL-OTHER:SELF-EVALUATE proposal already made.

Similar arguments to the above can be made for APPLY. The ultimate idea is
that user created objects can be treated as first class objects, just like
symbols.

Comments?

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂05-Oct-88  2312	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88  23:12:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471537; Thu 6-Oct-88 02:10:54 EDT
Date: Thu, 6 Oct 88 02:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: miller@CS.Rochester.EDU
cc: Common-Lisp-Object-System@SAIL.Stanford.EDU,
    CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-ID: <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 5 Oct 88 22:23 EDT
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>

    ... I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
    explicitly specifies the eval behavior. ...

The problem to this is that it's the same as allowing fexprs.  This is
something we've worked hard to eliminate from CL because it is opaque
to compilation.

You could argue that MACROEXPAND-1 should be a generic function I suppose.
I have no strong feeling on that subject right now, but I'm biased against
it because we are very close to casting this stuff in concrete and I don't
feel totally comfortable that I understand the consequences of doing so.

One minor procedural matter: You're more likely to get this considered if
you write up the proposal in full rather than just as a little fragment.
I count 194 cleanup topics that have been raised, and it's getting harder
and harder to `maintain' them. Some are destined to fall through the cracks
for lack of time and anything that people have a minor bias against can be
very easily pocket-veto'd if it doesn't come in in a form that we can
directly vote on...

∂06-Oct-88  1034	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  10:34:39 PDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 10:30:30 pdt
Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 10:30:06 pdt
Full-Name: Warren Harris
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        miller@CS.Rochester.EDU
Cc: Common-Lisp-Object-System@SAIL.Stanford.EDU, CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: EVAL-OTHER (Version 2) 
In-Reply-To: Your message of "Thu, 06 Oct 88 02:10:00 EDT."
             <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM> 
Date: Thu, 06 Oct 88 10:30:02 PDT
Message-Id: <8592.592162202@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>

I don't know about making EVAL a generic function due to the ramifications
this has on the compiler, but there are several other places in CL in which
functions should be required to be generic. 

One example might be in the equality area.  Common Lisp seems to have a
wealth of equality predicates, EQ, EQL, EQUAL, EQUALP, =, STRING=, CHAR=
... and you kind of pick and choose based on what you know about the
application.  It would be nice to have at least one version of equality
which did the right thing based on what it was comparing.  Perhaps this is
EQUALP.  EQUALP already looks inside both cons cells and arrays, why not
extend it to look inside objects too.  I suggest the following definition
of EQUALP:

	(defmethod equalp ((x t) (y t))
	  (eq x y))

        (defmethod equalp ((x character) (y character))
	  (char-equal x y))

        (defmethod equalp ((x number) (y number))
	  (= x y))

        (defmethod equalp ((x cons) (y cons))
	  (or (eq x y)
	      (and (equalp (car x) (car y))
		   (equalp (cdr x) (cdr y)))))

        (defmethod equalp ((x object) (y object))
	  (let ((cx (class-of x))
		(cy (class-of y)))
	    (or (eq x y)
		(and (eq cx cy)
		     (every #'(lambda (slotd)
				(let ((name (slotd-name slotd)))
				  (equalp (slot-value-using-class cx
								  x
								  name)
					  (slot-value-using-class cx
								  y
								  name))))
			    (class-slots cx))))))

        (defmethod equalp ((x array) (y array))
	  ...)

COERCE is another good candidate for being made generic.  Like the print
system which is required to go through the PRINT-OBJECT method, COERCE
could ultimately invoke a generic layer:

	(defun coerce (thing type)
	  (case type
	    <old coerce code ...>
	    (t
	     (coerce-object thing (find-class type)))))

	(defmethod coerce-object ((thing t) (c class))
	  (error "~S cannot be coerced to type ~S."
		 thing (class-name c)))

This would allow the user to write class specific coercion routines.  One
objection has been raised to this proposal by Moon:

> But it's meaningful for COERCE's second argument to be a type specifier that
> does not name a class.  CLtL gives as an example (vector (complex short-float)).
> It would be inconsistent to do some coercions with classes and others through
> some other mechanism.  I don't think your idea will work without a larger
> recasting of Common Lisp in object-oriented terms.  While that's an interesting
> project for investigation, I suspect it would quickly go way beyond the
> proper charter of a standardization effort.

I think the above code demonstrates how this can indeed work given CL's
non-class type specifiers.  COERCE itself is not required to be generic, it
is simplied required to ultimately call COERCE-OBJECT.  This is exactly the
requirement placed on PRINT. 

> One minor procedural matter: You're more likely to get this considered if
> you write up the proposal in full rather than just as a little fragment.

How do I do this?  How does it look, and who do I send it to?

Warren Harris
HP Labs

∂06-Oct-88  1156	Common-Lisp-Object-System-mailer 	Re: Q about CLOS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88  11:56:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 11:22:48 PDT
Date: Thu, 6 Oct 88 11:22 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Q about CLOS
To: miller@CS.ROCHESTER.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <19881005215228.4.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-ID: <19881006182238.0.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Wed, 5 Oct 88 17:52 EDT
    From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>

    None of the doc I've scrounged for CLOS answers this simple question, so
    anyone who can enlighten me, thanks...

    is EVAL a generic function (message)?

    is APPLY?

Neither of these is a generic-function.
-------

∂10-Oct-88  1352	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 10 Oct 88  13:52:43 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 59923; Mon 10-Oct-88 16:41:37 EDT
Date: Mon, 10 Oct 88 16:41 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2) 
To: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
cc: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
In-Reply-To: <881008-164009-2324@Xerox>
Message-ID: <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: 8 Oct 88 16:40 PDT
    From: masinter.pa@Xerox.COM

    The official procedure for participating in the Common Lisp Standardization
    effort is through your representitive to the X3J13 committee.

    While we're willing to accept proposals from the community at large,
    there's a large amount of work involved in the actual creation of the
    standard, and a fair amount of context. 

Well, I guess I'm part of the "community at large" but let me make one
inflammatory comment...

w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. It seems to
me the better approach is to make CLOS the language, and "traditional" CL
the subset. I know I would be a lot happier (as a heavy user of CL) that
way. I'd be happy to write this up as a formal proposal if that is what's
needed, but I don't really know what to do... edit Issue: EVAL-OTHER and
make it version 3, or do something else?

Asbestos suit on.

----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}

∂14-Oct-88  1510	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Oct 88  15:10:23 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 OCT 88 14:50:43 PDT
Date: 14 Oct 88 14:50 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EVAL-OTHER (Version 2) 
In-reply-to: Brad Miller <miller@CS.ROCHESTER.EDU>'s message of Mon, 10 Oct
 88 16:41 EDT
To: miller@CS.ROCHESTER.EDU
cc: common-lisp-object-system@SAIL.STANFORD.EDU
Message-ID: <881014-145043-7455@Xerox>

My impression from hearing about current applications of CLOS is that your
assertion "w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL"
is not true.

CLOS claim to integration in CL comes both from the integration of method
invocation with function call and the integration of the class hierarchy
with the previous Common Lisp type hierarchy. Both of those allow for
treating CLOS as the language and CLtL as the previous subset. CLOS and CL
are consistent in treating the type hierarchy as the mechanism of
dispatching on varying forms of behavior, but not relying too heavily on
the function-as-object style which is popular in Scheme.

The notion of making APPLY (or  FUNCALL) generic is possibly quite
interesting, although it implies a different model of "object oriented"
than the one currently embodied in Common Lisp and CLOS.

∂16-Oct-88  1316	Common-Lisp-Object-System-mailer 	CLOS analogue to TYPEP and SUBTYPEP 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Oct 88  13:16:48 PDT
Received: from blacksox ([192.9.201.39]) by LUCID.COM id AA04291g; Sun, 16 Oct 88 13:16:40 PDT
Received: by blacksox id AA00239g; Sun, 16 Oct 88 13:12:45 pdt
Date: Sun, 16 Oct 88 13:12:45 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810162012.AA00239@blacksox>
To: common-lisp-object-system@sail.stanford.edu
Subject: CLOS analogue to TYPEP and SUBTYPEP

I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS.
Given two class objects, I need to know whether one is a superclass of
the other.  I can't seem to find such a function in Chapter 2.  Have I
missed something, is this relegated to Chapter 3, or is there
something inherently bogus about what I'm trying to do?  It seems like
a rather ordinary thing, not terribly metaclassy.  This came up while
writing a program using CLOS that is intended to be a simple example.

∂16-Oct-88  1545	Common-Lisp-Object-System-mailer 	Re: CLOS analogue to TYPEP and SUBTYPEP  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Oct 88  15:45:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 16 OCT 88 15:45:05 PDT
Date: Sun, 16 Oct 88 15:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLOS analogue to TYPEP and SUBTYPEP
To: Eric Benson <eb@lucid.com>
cc: common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8810162012.AA00239@blacksox>
Message-ID: <19881016224404.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Sun, 16 Oct 88 13:12:45 pdt
    From: Eric Benson <eb@lucid.com>

    I am looking for a function analogous to TYPEP or SUBTYPEP in CLOS.
    Given two class objects, I need to know whether one is a superclass of
    the other.  I can't seem to find such a function in Chapter 2.  Have I
    missed something, is this relegated to Chapter 3, or is there
    something inherently bogus about what I'm trying to do?  It seems like
    a rather ordinary thing, not terribly metaclassy.  This came up while
    writing a program using CLOS that is intended to be a simple example.

According to CLOS, you should be able to pass class objects or class
names to subtypep and typep.  PCL hasn't yet arranged for this to work
for obvious reasons.

I believe there is a function in PCL called sub-class-p or subclassp
which does what you want.  I would check, but that isn't so easy just
now.
-------

∂20-Oct-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 2)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Oct 88  17:19:53 PDT
Received: from bhopal ([192.9.200.13]) by LUCID.COM id AA08318g; Thu, 20 Oct 88 17:19:26 PDT
Received: by bhopal id AA06100g; Thu, 20 Oct 88 17:17:51 PDT
Date: Thu, 20 Oct 88 17:17:51 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810210017.AA06100@bhopal>
To: miller@CS.ROCHESTER.EDU
Cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU, harris%hplwhh@HPLABS.HP.COM
In-Reply-To: Brad Miller's message of Mon, 10 Oct 88 16:41 EDT <19881010204134.1.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Subject: Issue: EVAL-OTHER (Version 2) 

re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

I can't agree with this at all.  CL is an extremely useful programming
language, and with CLOS added it is incredibly more  useful.  EVAL
is a boringly obscure operation to apply to any piece of data -- it
merely decodes the syntatic means by which programs are written.  Writing
programs encoded as strings rather than lists and symbols, or encoded in 
*any* other random datatype, is hardly a great step forward.

While that last sentence might be open to continuing theoretical debate,
there is the practical observation that MacLisp/NIL *did* make such an
extension (using the object-oriented system called EXTEND), and there
were virtually no meaningful uses of it.  [I'm not 100% sure but I think
Glenn Burke may have used it somehow in the Layered System Building
project.  Apologies, if that use was "meaningful".]

In fact, the EVAL-related extension that really has some vocal supporters
behind it is to *increase* the level on standardization in the coding of 
EVAL, so that research projects into the likes of debuggers and window 
systems can put more "hooks" into the interpreter.  See Henry Lieberman's
"Common Eval" proposal.


-- JonL --



∂24-Oct-88  1816	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
Received: from PECAN.CS.ROCHESTER.EDU ([192.5.53.206]) by SAIL.Stanford.EDU with TCP; 24 Oct 88  18:16:16 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by PECAN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 4702; Mon 24-Oct-88 21:07:30 EDT
Date: Mon, 24 Oct 88 21:06 EDT
From: Brad Miller <miller@CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2) 
To: Jon L White <jonl@LUCID.COM>
cc: masinter.pa@XEROX.COM, common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8810210017.AA06100@bhopal>
Message-ID: <19881025010655.7.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118

    Date: Thu, 20 Oct 88 17:17:51 PDT
    From: Jon L White <jonl@lucid.com>

    re: w/o generic EVAL or APPLY, CLOS is just a bag on the side of CL. 

    I can't agree with this at all.  CL is an extremely useful programming
    language, and with CLOS added it is incredibly more  useful.  EVAL
    is a boringly obscure operation to apply to any piece of data -- it
    merely decodes the syntatic means by which programs are written.  Writing
    programs encoded as strings rather than lists and symbols, or encoded in 
    *any* other random datatype, is hardly a great step forward.

    While that last sentence might be open to continuing theoretical debate,
    there is the practical observation that MacLisp/NIL *did* make such an
    extension (using the object-oriented system called EXTEND), and there
    were virtually no meaningful uses of it.  [I'm not 100% sure but I think
    Glenn Burke may have used it somehow in the Layered System Building
    project.  Apologies, if that use was "meaningful".]

    In fact, the EVAL-related extension that really has some vocal supporters
    behind it is to *increase* the level on standardization in the coding of 
    EVAL, so that research projects into the likes of debuggers and window 
    systems can put more "hooks" into the interpreter.  See Henry Lieberman's
    "Common Eval" proposal.


    -- JonL --

I plan on writing you a response to this, but I'm currently swamped;
just to let you know that my silence isn't agreement. I suspect the
fault was mostly mine: I only gave a trivial example of such use, and
I can give much better ones from my work on the RHET project.

The short cleanup is that while theoretically a full-blown generic
EVAL is "interesting", I certainly *don't* consider it practical. I'm
simply trying to allow the user to specify an eval-function for user
created types, rather than having them always self-eval. Generating
code for these types as (EVAL-YOURSELF <instance>) rather than
<instance> doesn't seem to be a particularly difficult implementation
problem, nor do I think it has a particular bad effect on debuggers.
Appropriate method combination for EVAL-YOURSELF should allow for a
debugger hook (though I've not thought this through carefully).

Thanks for your response.

More later,
----
Brad Miller		U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}