Mail Index

• Thread Index

• Introduction
  • From: RPG
• Please add me ty your group
  • From: Jerry Duggan <duggan@UTAH-20.ARPA>
• Chairman
  • From: RPG
• Re: Introduction
  • From: Stefik.pa@XEROX.ARPA
• Chairman
  • From: RPG
• Project description
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Hello folks
  • From: RPG
• Issues in object oriented programming in Common Lisp
  • From: Kahn.pa@XEROX.ARPA
• Different systems, variables
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Instance variables
  • From: Dave Dyer <DDYER@USC-ISIB.ARPA>
• Fundamental Flavors
  • From: Dave Dyer <DDYER@USC-ISIB.ARPA>
• Re: Instance variables
  • From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
• Instance variables
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Re: Instance variables
  • From: Kahn.pa@XEROX.ARPA
• Goals and Major Design Principles
  • From: AS%hplabs.csnet@csnet-relay.arpa
• Goals and Major Design Principles (violent reply)
  • From: Steven <Handerson%cmu-cs-c.arpa@csnet-relay.arpa>
• Goals
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• What are we talking about?
  • From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
• Goals
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• Re: What are we talking about?
  • From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
• What are we talking about?
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• Begging the question
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Goals?
  • From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
• Re: What are we talking about?
  • From: Kahn.pa@XEROX.ARPA
• Goals and Major Design Principles (violent reply)
  • From: "Robert W. Kerns" <RWK@SCRC-STONY-BROOK.ARPA>
• active values
  • From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
• Re: Status Of CL Object Oriented Group?
  • From: Kahn.pa@XEROX.ARPA
• Various thoughts and opinions
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Instance variables
  • From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
• [no subject]
  • From: RPG
• Re: Instance variables
  • From: Kahn.pa@XEROX.ARPA
• Re: Instance variables
  • From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
• Re: Instance variables
  • From: Kahn.pa@XEROX.ARPA
• Instance variables
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Re: Instance variables
  • From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
• Internals Proposal
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Internals Proposal
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Re: Internals Proposal
  • From: Bobrow.pa@XEROX.ARPA
• hooks vs. subset (last try)
  • From: Snyder%hplabs.csnet@csnet-relay.arpa
• Bobrow's message, Snyder's message, Flavors kernel
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• hooks vs. subset (last try)
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• Re: hooks vs. subset (last try)
  • From: Tom Bylander at Ohio State <BYLANDER@RUTGERS.ARPA>
• de facto standards
  • From: Snyder%hplabs.csnet@csnet-relay.arpa
• Clarificaiton Needed
  • From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
• Standardization (ugh)
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Standardization (ugh)
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• protocols/syntax, semantics of SEND, genericity
  • From: Kent M Pitman <KMP @ MIT-MC>
• Keywords as messages
  • From: Kent M Pitman <KMP @ MIT-MC>
• Messages as objects
  • From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
• Fahlman's mail, syntax and T operations, standard send
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• CAR sending a message, Liebermann's message
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Messages as objects
  • From: Jonathan A Rees <JAR @ MIT-MC>
• What are we up to?
  • From: Kahn.pa@XEROX.ARPA
• Messages as objects
  • From: HENRY%MIT-OZ@MIT-MC.ARPA
• Messages as objects
  • From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
• What are we up to?
  • From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
• What are we up to?
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• What are we up to?
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• Instance Variable Access
  • From: Bobrow.pa@XEROX.ARPA
• What are we up to?
  • From: Henry Lieberman <Henry%MIT-OZ@SCRC-STONY-BROOK.ARPA>
• Silence breaker
  • From: Henry Lieberman <Henry%MIT-OZ@SCRC-RIVERSIDE.ARPA>
• Compiling iv references efficiently, making CL object-oriented
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• flavors
  • From: Marion Hakanson <hakanson%oregon-state.csnet@csnet-relay.arpa>
• Whats Up?
  • From: Jon Sticklen <STICKLEN@RUTGERS.ARPA>
• Re: Whats Up?
  • From: Kahn.pa@XEROX.ARPA
• proposal
  • From: Snyder%hplabs.csnet@csnet-relay.arpa
• Query
  • From: Steven <Handerson@CMU-CS-C.ARPA>
• QLOGO
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• QLOGO?
  • From: George J. Carrette <GJC @ MIT-MC>
• MI reference
  • From: fischer@ru-opal (Ron Fischer)
• Synder's proposal
  • From: Kahn.pa@Xerox.ARPA
• Re: Snyder's proposal
  • From: Snyder%hplabs.csnet@csnet-relay.arpa
• Object-oriented programming & Common Lisp meeting
  • From: Kahn.pa@Xerox.ARPA
• Re: Object-oriented programming & Common Lisp meeting
  • From: Alan Snyder <AS%hplabs.csnet@csnet-relay.arpa>
• Object-oriented programming & Common Lisp meeting
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• Object-oriented programming & Common Lisp meeting
  • From: DDYER@SCRC-RIVERSIDE.ARPA
• Written proposals
  • From: Kahn.pa@Xerox.ARPA
• Object-oriented programming & Common Lisp meeting
  • From: Howard I. Cannon <HIC@SCRC-STONY-BROOK.ARPA>
• Xerox proposal to be mailed
  • From: Stefik.pa@Xerox.ARPA
• Re: Xerox proposal to be mailed
  • From: Jane Laursen <janel%tekchips%tektronix.csnet@csnet-relay.arpa>
• IJCAI meeting (time and place)
  • From: Kahn.pa@Xerox.ARPA
• CommonLoops paper mailed
  • From: Masinter.pa@Xerox.ARPA
• Common LOOPS
  • From: Guy Steele <gls@THINK-AQUINAS.ARPA>
• Type specification of &optional arguments.
  • From: Gregor.pa@Xerox.ARPA
• CommonLoops
  • From: kessler%utah-orion@utah-cs.arpa (Robert Kessler)
• Re: CommonLoops
  • From: Gregor.pa@Xerox.ARPA
• CommonLoops
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• [GLD%MIT-OZ@MIT-MC.ARPA: ObjectLisp]
  • From: Kahn.pa@Xerox.ARPA
• Sincere apologies
  • From: Guy Steele <gls@THINK-AQUINAS.ARPA>
• Common LOOPS questions
  • From: Jonathan A Rees <JAR@MIT-MC.ARPA>
• Re: Common LOOPS questions
  • From: Masinter.pa@Xerox.ARPA
• correction on mlet & mlabels
  • From: masinter.PA@Xerox.ARPA
• correction on mlet & mlabels
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• Re: correction on mlet & mlabels
  • From: masinter.PA@Xerox.ARPA
• Mlet & Mlabels
  • From: RPG
• Meeting at IJCAI
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• Response to Masinter's multi-slot idea
  • From: Kahn.pa@Xerox.ARPA
• Re: Response to Masinter's multi-slot idea
  • From: Kahn.pa@Xerox.ARPA
• Questions about Commonloops
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• CommonLoops discussion.
  • From: Gregor.pa@Xerox.ARPA
• Re: Questions about Commonloops
  • From: Gregor.pa@Xerox.ARPA
• the :allocation slot option
  • From: Gregor.pa@Xerox.ARPA
• Re: CommonLoops discussion.
  • From: Tribble.pa@Xerox.ARPA
• Questions about Commonloops
  • From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
• Re: LISP has both pure and reference data types
  • From: Masinter.pa@Xerox.ARPA
• [Masinter.pa: Re: Questions about Commonloops]
  • From: Bobrow.pa@Xerox.ARPA, Kahn.pa@Xerox.ARPA, Masinter.pa@Xerox.ARPA
• [no subject]
  • From: Bobrow.pa@Xerox.ARPA
• [no subject]
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Notes IJCAI mewtting of Common Lisp Object Committee
  • From: Bobrow.pa@Xerox.ARPA
• Name conflicts for names of instance variables
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• slot shadowing
  • From: Dave.Touretzky@A.CS.CMU.EDU
• slot shadowing
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• Arguments and values to get.
  • From: Gregor.pa@Xerox.ARPA
• Arguments and values to get.
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Arguments and values to get.
  • From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
• A reply and some more thoughts on specializing built-in functions
  • From: masinter.pa@Xerox.ARPA
• Re: EQUAL isn't really correct, I agree
  • From: masinter.pa@Xerox.ARPA
• A reply and some more thoughts on specializing built-in
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• reply to Moon on slot shadowing
  • From: Dave.Touretzky@A.CS.CMU.EDU
• Re: A reply and some more thoughts on specializing built-in
  • From: Bobrow.pa@Xerox.ARPA
• CommonLoops
  • From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
• SPECIALIZABLE(-)P
  • From: Dave.Touretzky@A.CS.CMU.EDU
• CommonLoops
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• A reply and some more thoughts on specializing built-in
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• CommonLoops & Flavors' complexity
  • From: DDYER@SCRC-RIVERSIDE.ARPA
• CommonLoops
  • From: Robert W. Kerns <RWK@SCRC-YUKON.ARPA>
• [no subject]
  • From: Bobrow.pa@Xerox.ARPA
• [no subject]
  • From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
• Complexity, yet again
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Complexity, yet again
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• Complexity, yet again
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Complexity, yet again
  • From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
• Complexity, yet again
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Re: ---
  • From: Bobrow.pa@Xerox.ARPA
• Re: ---
  • From: Alan Snyder <AS%hplabs.csnet@CSNET-RELAY.ARPA>
• Re: slot shadowing
  • From: snyder%hplabs.csnet@CSNET-RELAY.ARPA
• Arguments and values to get.
  • From: David C. Plummer <DCP@SCRC-QUABBIN.ARPA>
• addn to the mailing list.
  • From: S Sridhar <sridhar%tekchips%tektronix.csnet@CSNET-RELAY.ARPA>
• Call for Papers OOPSLA86
  • From: RPG
• CommonLoops meets Object Lisp
  • From: CommonLoopsCore↑.pa@Xerox.ARPA
• March 24, 1986 Electronic Engineering Times article
  • From: masinter.pa@Xerox.COM
• Re: March 24, 1986 Electronic Engineering Times article
  • From: Jim Kempf <kempf%hplabsc@hplabs.ARPA>
• Re: March 24, 1986 Electronic Engineering Times article
  • From: Masinter.pa@Xerox.COM
• two questions about New Flavors
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• two questions about New Flavors
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• accessor functions
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• accessor functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: accessor functions
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• Re: accessor functions
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• Re: accessor functions
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• Re: accessor functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: accessor functions
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• Re: accessor functions
  • From: Dan Carnese <Carnese@SRI-KL>
• Re: accessor functions
  • From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
• Re: accessor functions
  • From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
• Re: accessor functions
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• Re: accessor functions
  • From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
• Re: accessor functions
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• [no subject]
  • From: Carnese@SRI-KL
• Re: ---
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• Re: accessor functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• accessor functions
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• operation naming conventions
  • From: Dan Carnese <CARNESE@SRI-KL.ARPA>
• Re: operation naming conventions
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• Re: operation naming conventions
  • From: Dan Carnese <Carnese@SRI-KL>
• Re: operation naming conventions
  • From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>
• Summary of CL OOP Meeting on August 6
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• Portable CommonLoops Export Status
  • From: Gregor Kiczales <Gregor.pa@Xerox.COM>
• OOPSLA'86
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• nested class definitions
  • From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>
• Re: nested class definitions
  • From: Kahn.pa@Xerox.COM
• Re: nested class definitions
  • From: Masinter.pa@Xerox.COM
• Re: nested class definitions
  • From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
• Mailing list addition
  • From: "Steve Mitchell" <SMITCHELL@USC-ECL.ARPA>
• Re: CLX draft 3 revisions
  • From: Gregor.pa@Xerox.COM
• Re: CLX draft 3 revisions
  • From: cperdue@Sun.COM (Cris Perdue)
• Re: CLX draft 3 revisions
  • From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
• Re: CLX draft 3 revisions
  • From: Dan Carnese <CARNESE@SPAR-20.ARPA>
• Re: CLX draft 3 revisions
  • From: Gregor.pa@Xerox.COM
• Re: CLX draft 3 revisions
  • From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
• Re: CLX draft 3 revisions
  • From: Dan Carnese <CARNESE@SPAR-20.ARPA>
• Please remove...
  • From: Alan Schultz <schultz@nrl-aic.ARPA>
• Re: [Dan Carnese <CARNESE@SPAR-20.ARPA>: Re: CLX draft 3 revisions
  • From: Dan Carnese <CARNESE@SPAR-20.ARPA>
• Put me on the CL-Object-Oriented-Programming Mailing List
  • From: "Jin H. Kim" <jkim%csd.kaist.ac.kr@RELAY.CS.NET>
• OOPSLA Lisp and Object-Oriented Programming Workshop
  • From: RPG
• CLOS
  • From: kgk%cs.brown.edu@RELAY.CS.NET
• CLOS
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: CLOS
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• CLOS
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Re: CLOS
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• CLOS
  • From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
• Re: CLOS
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: no-applicable-method
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• Shared/class;local/instance
  • From: RPG
• [goldman@vaxa.isi.edu: miscellaneous CLOS topics]
  • From: Gregor.pa@Xerox.COM
• meeting at x3j13
  • From: Gregor.pa@Xerox.COM
• Shared/class;local/instance
  • From: Gregor.pa@Xerox.COM
• meeting at x3j13
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Shared/class;local/instance
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Writing
  • From: RPG
• Extent of CALL-NEXT-METHOD
  • From: RPG
• shared/class;local/instance
  • From: RPG
• Re: Shared/class;local/instance
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: meeting at x3j13
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Extent of CALL-NEXT-METHOD
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Extent of CALL-NEXT-METHOD
  • From: Gregor.pa@Xerox.COM
• Re: Extent of CALL-NEXT-METHOD
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Extent of CALL-NEXT-METHOD
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: meeting at x3j13
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Extent of CALL-NEXT-METHOD
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Shared/class;local/instance
  • From: kempf%hplabsz@hplabs.HP.COM
• extent of CALL-NEXT-METHOD
  • From: MASINTER.PA@Xerox.COM
• Extent of CALL-NEXT-METHOD
  • From: Gregor.pa@Xerox.COM
• fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Extent of CALL-NEXT-METHOD
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Constructors
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• [no subject]
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: fixing our problems with setf
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Shared/class;local/instance
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Shared/class;local/instance
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Object Creation Writeup
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Object Creation Writeup
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Status
  • From: RPG
• Name Change for Metaobject Protocol?
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Name Change for Metaobject Protocol?
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Name Change for Metaobject Protocol?
  • From: Gregor.pa@Xerox.COM
• fixing our problems with setf
  • From: Gregor.pa@Xerox.COM
• Extent of CALL-NEXT-METHOD
  • From: Gregor.pa@Xerox.COM
• reinitializing class slots
  • From: Gregor.pa@Xerox.COM
• fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• fixing our problems with setf
  • From: Gregor.pa@Xerox.COM
• Re: fixing our problems with setf
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: fixing our problems with setf
  • From: Pavel.pa@Xerox.COM
• Re: fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: fixing our problems with setf
  • From: Pavel.pa@Xerox.COM
• status of "object" or "standard-object"
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: status of "object" or "standard-object"
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Name Change for Metaobject Protocol?
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Status (and TRACE-EXECUTION spec)
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Constructors
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: fixing our problems with setf
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Name Change for Metaobject Protocol?
  • From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
• CLASS-CHANGED and UPDATE-OBSOLETE-INSTANCE
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Constructors
  • From: RPG
• The Results are In!
  • From: RPG
• Re: The Results are In!
  • From: kempf%hplabsz@hplabs.HP.COM
• initialize-instance on an exisiting instance
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• initialize-instance on an exisiting instance
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: The Results are In!
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: initialize-instance on an exisiting instance
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Constructors
  • From: RPG
• Re: Constructors
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Constructors
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Constructors
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• The Latest Draft
  • From: RPG
• The extent of CALL-NEXT-METHOD (a retraction)
  • From: Pavel.pa@Xerox.COM
• Re: The extent of CALL-NEXT-METHOD (a retraction)
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Constructors
  • From: kempf%hplabsz@hplabs.HP.COM
• indefinite extent of call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• TRACE Proposal
  • From: kempf%hplabsz@hplabs.HP.COM
• indefinite extent of call-next-method
  • From: Gregor.pa@Xerox.COM
• Re: Constructors
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Re: Constructors
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Extent
  • From: RPG
• First round of comments on the draft document
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Clear Versus Black Box
  • From: RPG
• 0-ary generic functions
  • From: RPG
• Pavel's Comments
  • From: RPG
• My comments on Chapter 1
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: indefinite extent of call-next-method
  • From: kempf%hplabsz@hplabs.HP.COM
• Rest of comments on chapter 1 of the draft document
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: indefinite extent of call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Constructors
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Keene comments on Chapter 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: indefinite extent of call-next-method
  • From: Masinter.pa@Xerox.COM
• Comments on chapter 2, through defgeneric
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: indefinite extent of call-next-method
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Extent
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Comments on comments on Chapter 1
  • From: Pavel.pa@Xerox.COM
• Comments on comments on Chapter 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Comments on comments on Chapter 1
  • From: Pavel.pa@Xerox.COM
• Re: Clear Versus Black Box
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Second set of comments on chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• 0-ary generic functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Comments on comments on Chapter 1
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: First round of comments on the draft document
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Comments on comments on Chapter 1
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: 0-ary generic functions
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• comments on some standard type classes
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• standard-type-class or built-in-class
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Pavel
  • From: RPG
• My comments on Chapter 1
  • From: Pavel.pa@Xerox.COM
• Undefined Definition
  • From: RPG
• Adjustable Arrays and Error Terminology
  • From: RPG
• Comments on final portion of Chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Constructors
  • From: kempf%hplabsz@hplabs.HP.COM
• Comments on (the skeleton of) Chapter 3
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Extent
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Comments on comments on Chapter 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Class naming
  • From: Pavel.pa@Xerox.COM
• Re: Pavel's Comments
  • From: Pavel.pa@Xerox.COM
• Re: Pavel's Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on Chapter 1
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Undefined Definition
  • From: Pavel.pa@Xerox.COM
• More comments on the draft document
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• More on Class names
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• More on Class names
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Environment-arguments, MACRO-FUNCTION-ENVIRONMENT
  • From: Masinter.pa@Xerox.COM
• status of "object" or "standard-object"
  • From: Gregor.pa@Xerox.COM
• "Object" Class.
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Some open issues
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Proof of CLOS Document
  • From: kempf%hplabsz@hplabs.HP.COM
• Proof of CLOS Document
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• status of "object" or "standard-object"
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Some open issues
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Proof of CLOS Document
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Some open issues
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• comments on revised Chapter 1
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Some open issues
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• standard type class
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: standard type class
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Some open issues
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• comments on portions of the Oct 26 10:05 draft
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• :accessor slot option
  • From: Gregor.pa@Xerox.COM
• Comments on chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comment on the chapter 2.
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Comment on the chapter 2, Version of Nov 2.
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• CLOS mailing list
  • From: mcvax!crin.crin.fr!masini@uunet.UU.NET
• CLOS mailing list
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comment on the chapter 2, Version of Nov 2.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issues raised by comments on chapter 2
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Lambda-list in Defgeneric
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Issues raised by comments on chapter 2
  • From: Gregor.pa@Xerox.COM
• method signatures
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Issues raised by comments on chapter 2
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• format for description of generic functions in chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Comment on the chapter 2, Version of Nov 2.
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• State of Affairs
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• lambda-list in defgeneric
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• lambda-list in defgeneric, generic-flet, etc.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• format for description of generic functions in chapter 2
  • From: Gregor.PA@Xerox.COM, Bobrow.PA@Xerox.COM
• ambiguity in defgeneric and method descriptions
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: lambda-list in defgeneric, generic-flet, etc.
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: ambiguity in defgeneric and method descriptions
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Defgeneric affects methods?
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: format for description of generic functions in chapter 2
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• CALL-NEXT-METHOD example
  • From: Gregor.pa@Xerox.COM
• CALL-NEXT-METHOD example
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: ambiguity in defgeneric and method descriptions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Chapter 1 typos.
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• CALL-NEXT-METHOD example
  • From: Gregor.pa@Xerox.COM
• setf of class-name
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Defgeneric affects methods?
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Defgeneric affects methods?
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: format for description of generic functions in chapter 2
  • From: Masinter.pa@Xerox.COM
• Current State of CLOS Draft
  • From: kempf%hplabsz@hplabs.HP.COM
• Agenda for X3J13
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Agenda for X3J13
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• making gf lambda lists
  • From: Gregor.pa@Xerox.COM
• scope of call-next-method
  • From: Gregor.pa@Xerox.COM
• optimization in the spec
  • From: Gregor.pa@Xerox.COM
• scope of call-next-method
  • From: Gregor.pa@Xerox.COM
• scope of call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• scope of call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: optimization in the spec
  • From: kempf%hplabsz@hplabs.HP.COM
• Scope of Call-next-method
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• optimization in the spec
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• questions about CLOS [original subject: equality of structures]
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• symbol-macrolet
  • From: Gregor.pa@Xerox.COM
• Re: symbol-macrolet
  • From: kanderso@WILMA.BBN.COM
• Re: symbol-macrolet
  • From: Gregor.pa@Xerox.COM
• Re: symbol-macrolet
  • From: Gregor.pa@Xerox.COM
• Re: symbol-macrolet
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• symbol-macrolet
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• symbol-macrolet
  • From: Gregor.pa@Xerox.COM
• making gf lambda lists
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: making gf lambda lists
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• :accessor slot option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: symbol-macrolet
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: :accessor slot option
  • From: kempf%hplabsz@hplabs.HP.COM
• mop
  • From: Gregor.pa@Xerox.COM
• MOP comments part 1.
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• the mop
  • From: Gregor.pa@Xerox.COM
• MOP comments part 1.
  • From: Gregor.pa@Xerox.COM
• Re: MOP comments part 1.
  • From: Danny bobrow <bobrow.pa@Xerox.COM>
• MOP Comments Part 2.
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• MOP Comments Part 2.
  • From: Gregor.pa@Xerox.COM
• MOP Comments (Repost)
  • From: kempf%hplabsz@hplabs.HP.COM
• MOP Comments (Repost) - 2 3 4 5a
  • From: Gregor.pa@Xerox.COM
• Re: MOP Comments (Repost) - 2 3 4 5a
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• Meeting next week
  • From: Danny bobrow <bobrow.pa@Xerox.COM>
• Re: MOP Comments (Repost) - 2 3 4 5a
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: MOP Comments (Repost) - 2 3 4 5a
  • From: Gregor.pa@Xerox.COM
• Re: Meeting next week
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Re: Meeting next week
  • From: Danny bobrow <bobrow.pa@Xerox.COM>
• Re: Meeting next week
  • From: kempf%hplabsz@hplabs.HP.COM
• new version of mop
  • From: Gregor.pa@Xerox.COM
• Meeting Next Week
  • From: Gregor.pa@Xerox.COM
• Comments on MOP
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Meeting Next Week
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Further Reaction to MOP
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• meeting next week
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• new version of mop
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• [no subject]
  • From: "Gregor J. Kiczales" <GREGOR@AI.AI.MIT.EDU>
• MOP Goals
  • From: kempf%hplabsz@hplabs.HP.COM
• Versioning
  • From: kempf%hplabsz@hplabs.HP.COM
• Versioning
  • From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
• Re: Versioning
  • From: kempf%hplabsz@hplabs.HP.COM
• MOP and Inheritance
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Versioning
  • From: kempf%hplabsz@hplabs.HP.COM
• MOP and Inheritance
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Re: MOP and Inheritance
  • From: kempf%hplabsz@hplabs.hp.com
• with-accessors
  • From: Gregor.pa@Xerox.COM
• Concep.tex
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• add-method when method exists
  • From: Gregor.pa@Xerox.COM
• New Class Organization for CLOS Kernel
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• reinitialize-instance
  • From: Bobrow.pa@Xerox.COM
• Proposed New Outline For MOP Kernel
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• New Specializers For CLOS
  • From: Bobrow.pa@Xerox.COM
• CALL-NEXT-METHOD Winter Solstice present
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: add-method when method exists
  • From: kanderso@WILMA.BBN.COM
• Re: add-method when method exists
  • From: kanderso@WILMA.BBN.COM
• CALL-NEXT-METHOD Winter Solstice present
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: CALL-NEXT-METHOD Winter Solstice present
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: New Specializers For CLOS
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: with-accessors
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: CALL-NEXT-METHOD Winter Solstice present
  • From: kempf%hplabsz@hplabs.HP.COM
• with-accessors
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: add-method when method exists
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• New Class Organization for CLOS Kernel
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• with-accessors
  • From: Gregor.pa@Xerox.COM
• partial results of Cambridge meeting
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on Chapter 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Standardizing the macroexpansion of make-method-call
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on Chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: with-accessors
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• New Class Organization for CLOS Kernel
  • From: Gregor.pa@Xerox.COM
• Standardizing the macroexpansion of make-method-call
  • From: Gregor.pa@Xerox.COM
• Re: New Specializers For CLOS
  • From: Danny bobrow <bobrow.pa@Xerox.COM>
• CALL-NEXT-METHOD
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Chapter 3 and the Cambridge Meeting
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: CALL-NEXT-METHOD
  • From: Danny bobrow <bobrow.pa@Xerox.COM>
• CALL-NEXT-METHOD
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• call-method proposal
  • From: Gregor.pa@Xerox.COM
• CALL-NEXT-METHOD
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• call-method proposal prime
  • From: Gregor.pa@Xerox.COM
• call-method proposal prime prime
  • From: Gregor.pa@Xerox.COM
• defmethod-setf
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• defmethod-setf
  • From: Gregor.pa@Xerox.COM
• functi.dvi
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• CALL-NEXT-METHOD and funcall-qua/send-as
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• is the functi.dvi file trashed?
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: defmethod-setf
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• Re: Method Combination Objects
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Defmethod-setf
  • From: Gregor.pa@Xerox.COM
• Sonya's problem with functi.dvi
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: add-method when method exists
  • From: Patrick H Dussud <DUSSUD%jenner.csc.ti.com@RELAY.CS.NET>
• call-method proposal prime prime
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Standardizing the macroexpansion of make-method-call
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-method proposal prime prime
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• DEFMETHOD Specification
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• method-lambda
  • From: Gregor.pa@Xerox.COM
• Re: call-method proposal prime prime
  • From: Gregor.pa@Xerox.COM
• Re: call-method proposal prime prime
  • From: vijay <saraswat.pa@Xerox.COM>
• Re: Method Combination Objects
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Alternative Proposal for class updating
  • From: Bobrow.pa@Xerox.COM
• DEFMETHOD Specification
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• add-method
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• Object Lisp vs CLOS in BYTE (Jan 88)
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• some questions on your chapter 2 comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: some questions on your chapter 2 comments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: some questions on your chapter 2 comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: add-method
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: some questions on your chapter 2 comments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Remarks
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• ADD-METHOD
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• functi
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• METHOD-LAMBDA and Removing parsing
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: CALL-NEXT-METHOD and funcall-qua/send-as
  • From: kempf%hplabsz@hplabs.HP.COM
• Remarks
  • From: Gregor.pa@Xerox.COM
• Re: ADD-METHOD
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• ADD-METHOD
  • From: Gregor.pa@Xerox.COM
• Re: New Class Organization for CLOS Kernel
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Class organization for CLOS kernel
  • From: Bobrow.pa@Xerox.COM
• Comments on latest draft documents
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Alternative Proposal for class updating
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Type-checking of slot values
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Type-checking of slot values
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Type-checking of slot values
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Type-checking of slot values
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Re: Type-checking of slot values
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Type-checking of slot values
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Type-checking of slot values
  • From: kempf%hplabsz@hplabs.HP.COM
• Type-checking of slot values
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Re: Type-checking of slot values
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Type-checking of slot values
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Typechecking
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Method Combination Objects
  • From: Gregor.pa@Xerox.COM
• Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Type-checking of slot values
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Method Combination Objects
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• call-method proposal prime prime
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Type-checking of slot values
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Re: Method Combination Objects
  • From: Patrick H Dussud <dussud@jenner.csc.ti.com>
• call-method proposal
  • From: Patrick H Dussud <dussud@jenner.csc.ti.com>
• Method Combination Objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• reinitialization protocol
  • From: Gregor.pa@Xerox.COM
• class updating protocol
  • From: Gregor.pa@Xerox.COM
• call-method proposal prime prime
  • From: Gregor.pa@Xerox.COM
• call-method proposal prime prime
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: class updating protocol
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Re: reinitialization protocol
  • From: kempf%hplabsz@hplabs.HP.COM
• Re: class updating protocol
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Comments on latest draft documents
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: reinitialization protocol
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: class updating protocol
  • From: Gregor.pa@Xerox.COM
• Re: reinitialization protocol
  • From: Gregor.pa@Xerox.COM
• call-method proposal prime prime
  • From: Gregor.pa@Xerox.COM
• Re: class updating protocol
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Remarks about Comments on Latest Draft Documents
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Comments on latest draft documents
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Chapter 1
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Chapter 2
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• Re: Remarks about Comments on Latest Draft Documents
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Class Names (Again! Can't We Ever Stop?)
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Names, Names
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Comments on most recent draft: Chap 1 and 2
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Class Names (Again! Can't We Ever Stop?)
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Names
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Chapter 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Chapter 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Names, Names
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Names, Names
  • From: Ken Kahn <Kahn.pa@Xerox.COM>
• Comments on most recent draft: Chap 1 and 2
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Re: Comments on most recent draft: Chap 1 and 2
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Naming
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Comments on most recent draft: Chap 1 and 2
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• CONCEP and FUNCTI
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Naming
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Naming
  • From: Gregor.pa@Xerox.COM
• Typechecking
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Defgeneric
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Naming
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Re: Naming
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Naming
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Type-checking of slot values
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Typechecking
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Typechecking
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Typechecking
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• defgeneric :method option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• DEFGENERIC
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Typechecking
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Re: Typechecking
  • From: Gregor.pa@Xerox.COM
• Typechecking
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Typechecking
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Chapter 2
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• Chapter 1
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Typechecking
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• x3j13 draft
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• Re: defgeneric :method option
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• Re: defgeneric :method option
  • From: Patrick H Dussud <DUSSUD@jenner.csc.ti.com>
• DEFGENERIC
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• CONCEP and FUNCTI
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: defgeneric :method option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on most recent draft: Chap 1 and 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: defgeneric :method option
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: defgeneric :method option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on most recent draft: Chap 1 and 2
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Status of SETF functions in Common Lisp
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Status of SETF functions in Common Lisp
  • From: masinter.PA@Xerox.COM
• Comments on most recent draft: Chap 1 and 2
  • From: "Robert W. Kerns" <RWK@ai.ai.mit.edu>
• Status of SETF functions in Common Lisp
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Issue: SETF-SUB-METHODS
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Issue: SETF-SUB-METHODS
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Method Combination
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• SLOT-BOUNDP
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• 88-002 question
  • From: Pavel.pa@Xerox.COM
• 88-002 Comment
  • From: Pavel.pa@Xerox.COM
• new version of mop
  • From: Gregor.pa@Xerox.COM
• Re: new version of mop
  • From: mcvax!inria.inria.fr!cointe@uunet.UU.NET (Pierre Cointe)
• Small omission in Chap 2
  • From: fritzson@PRC.Unisys.COM (Richard Fritzson)
• Small omission in Chap 2
  • From: Gregor.pa@Xerox.COM
• CLOS Consortium
  • From: Linda G. DeMichiel <edsel!lgd@labrea.Stanford.EDU>
• new version of mopc
  • From: Gregor.pa@Xerox.COM
• Proposed Wording Change to the Error Terminology
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Proposed Wording Change to the Error Terminology
  • From: Dick Gabriel <grian!elroy!RPG%SAIL.Stanford.EDU@elroy.Jpl.Nasa.Gov>
• Proposed Wording Change to the Error Terminology
  • From: Dick Gabriel <grian!elroy!grian!elroy!RPG%SAIL.Stanford.EDU@elroy.Jpl.Nasa.Gov>
• Proposed Wording PicoChange to the Error Terminology
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Proposed Wording Change to the Error Terminology (II)
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• CLOS Status
  • From: "James_L_Mayer.WBST128"@Xerox.COM
• Proposed Wording PicoChange to the Error Terminology
  • From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
• Proposed Wording Change to the Error Terminology
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Proposed Wording Change to the Error Terminology
  • From: Pavel.pa@Xerox.COM
• Proposed Wording Change to the Error Terminology (II)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Error Terminology
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Proposed Wording Change to the Error Terminology (II)
  • From: Gregor.pa@Xerox.COM
• Proposed Wording Change to the Error Terminology (II)
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Error Terminology
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• D'4 Example
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Undefined
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Some early comments on 88-003
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Error Terminology
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• D'4 Example
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• D'4 Example
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Error Terminology
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Error Terminology
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Ch3
  • From: kempf@Sun.COM
• Method-lambda and apply-method-lambda
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Method-lambda and apply-method-lambda
  • From: kempf@Sun.COM
• Re: Error Terminology
  • From: Masinter.pa@Xerox.COM
• Re: Method-lambda and apply-method-lambda
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Method-lambda and apply-method-lambda
  • From: Gregor.pa@Xerox.COM
• Error Terminology
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Error Terminology
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• CLOS, and slot hiding.
  • From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com after 1-April-88)
• Re: CLOS, and slot hiding.
  • From: kempf@Sun.COM
• Method-lambda and apply-method-lambda
  • From: dussud@ausome.csc.ti.com
• add-named-xxx
  • From: Gregor.pa@Xerox.COM
• Some early comments on 88-003 (accessor methods)
  • From: Gregor.pa@Xerox.COM
• update-instance-structure
  • From: Gregor.pa@Xerox.COM
• Reinitialization
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• (re)initialization revisited
  • From: Gregor.PA@Xerox.COM, Bobrow.PA@Xerox.COM
• comments from Kathy Chapman
  • From: Gregor.pa@Xerox.COM
• Re: CLOS, and slot hiding.
  • From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)
• Re: CLOS, and slot hiding.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: CLOS, and slot hiding.
  • From: kempf@Sun.COM
• Re: CLOS, and slot hiding.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: CLOS, and slot hiding.
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Reinitialization
  • From: Gregor.pa@Xerox.COM
• Reinitialization
  • From: Gregor.pa@Xerox.COM
• Reinitialization
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Reinitialization
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Reinitialization
  • From: Gregor.pa@Xerox.COM
• Re: (re)initialization revisited
  • From: kempf@Sun.COM
• Re: (re)initialization revisited
  • From: Gregor.pa@Xerox.COM
• Reinitialization
  • From: Gregor.pa@Xerox.COM
• update-instance-structure
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Re: CLOS, and slot hiding.
  • From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)
• Re: CLOS, and slot hiding.
  • From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)
• Re: (re)initialization revisited
  • From: kempf@Sun.COM
• Re: CLOS, and slot hiding.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Method-lambda and apply-method-lambda
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Method-lambda and apply-method-lambda
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• comments on CLOS draft 88-2
  • From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)
• comments on CLOS draft 88-2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: comments on CLOS draft 88-2
  • From: kempf@Sun.COM
• Re: comments on CLOS draft 88-2
  • From: kanderso@WILMA.BBN.COM
• add-named-xxx
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: kempf@Sun.COM
• comments on CLOS draft 88-2
  • From: Gregor.pa@Xerox.COM
• method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: (re)initialization revisited
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• add-named-xxx
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• Re: method-lambda and apply-method-lambda
  • From: kempf@Sun.COM
• Re: method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• dependent update protocol
  • From: Gregor.pa@Xerox.COM
• lattice of kernel classes
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• dependent update protocol
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: lattice of kernel classes
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: lattice of kernel classes
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• method-lambda and apply-method-lambda
  • From: Gregor.pa@Xerox.COM
• method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: method-lambda and apply-method-lambda
  • From: kempf@Sun.COM
• Re: method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• method-lambda and apply-method-lambda
  • From: Gregor.pa@Xerox.COM
• Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• two questions about standard-class
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• method-lambda and apply-method-lambda
  • From: Gregor.pa@Xerox.COM
• Re: Reinitialization
  • From: kempf@Sun.COM
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: kanderso@WILMA.BBN.COM
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Please forward this mail to CLOS mailing-list
  • From: Unknown
• Announcing New Journal on Object-Oriented Programming
  • From: kempf@Sun.COM
• Re: method-lambda and apply-method-lambda
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• two questions about standard-class
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: kempf@Sun.COM
• corrections to Chapter 1
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: two questions about standard-class
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Reinitialization
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• add-named-xxx
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Chapter 1 and 2 Last Chance Review
  • From: Dan L. Pierson <pierson%mist@multimax.ARPA>
• add-named-xxx
  • From: Gregor.pa@Xerox.COM
• Chapter 1 and 2 Last Chance Review
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Chapter 1 and 2 Last Chance Review
  • From: Dan L. Pierson <pierson%mist@multimax.ARPA>
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: kempf@Sun.COM
• Responses
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• promises
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Chapter 1 and 2 Last Chance Review
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• promises
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: promises
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• CLOS consortium
  • From: Chris Richardson <mcvax!harlqn.co.uk!chris@uunet.UU.NET>
• Re: dependent update protocol
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: kempf@Sun.COM
• Re: MAKE-METHOD-FUNCTION and APPLY-METHOD
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: method-lambda and apply-method-lambda
  • From: Gregor.pa@Xerox.COM
• Comment on CLOS
  • From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
• CLOS comments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: dependent update protocol
  • From: kanderso@WILMA.BBN.COM
• DEADLINE for finishing 1 and 2
  • From: Gregor.pa@Xerox.COM
• dependent update protocol
  • From: Gregor.pa@Xerox.COM
• dependent update protocol
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• dependent update protocol
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• dependent update protocol
  • From: Gregor.pa@Xerox.COM
• Re: dependent update protocol
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• DEADLINE for finishing 1 and 2
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• DEADLINE for finishing 1 and 2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: method-lambda and apply-method-lambda
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• comments on CLOS draft 88-2
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• dependent update protocol
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• some comments on CLOS
  • From: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>
• Sun Opposition To Chapter 3 Hereby Tendered
  • From: kempf@Sun.COM
• Re: dependent update protocol
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: dependent update protocol
  • From: Gregor.pa@Xerox.COM
• reinitialization etc
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Reinitialization
  • From: Gregor.pa@Xerox.COM
• subcommittee meeting
  • From: Gregor.pa@Xerox.COM
• Re: Reinitialization
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: Gregor.pa@Xerox.COM
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• X3 subcommittee meeting in June
  • From: Jan Zubkoff <edsel!jlz@labrea.Stanford.EDU>
• dealing with 1+2 comments
  • From: Gregor.pa@Xerox.COM
• editorial comments
  • From: Gregor.pa@Xerox.COM
• Editorial Comments and My Disposition of Them
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• "Written Responses" to CLOS 88-002: SETF Functions
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• "Written Responses" to CLOS 88-002: SYMBOL-CLASS is poorly named
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• "Written Responses" to CLOS 88-002: (Re)Initialization
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• belated editorial comment
  • From: Gregor.pa@Xerox.COM
• belated editorial comment
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• "Written Responses" to CLOS 88-002: SETF Functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: "Written Responses" to CLOS 88-002: SYMBOL-CLASS is poorly named
  • From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
• Re: Reinitialization
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Reinitialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• "Written Responses" to CLOS 88-002: SETF Functions
  • From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
• type slot option
  • From: Gregor.pa@Xerox.COM
• documentation slot option
  • From: Gregor.pa@Xerox.COM
• generic-function special form
  • From: Gregor.pa@Xerox.COM
• no-next-method lexical function
  • From: Gregor.pa@Xerox.COM
• symbol-class is bad name
  • From: Gregor.pa@Xerox.COM
• Re: Reinitialization: check-initargs
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Recovery
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Reinitialization: check-initargs
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• type slot option
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• FIND-CLASS
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Re: symbol-class is bad name
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• generic-function special form
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• no-next-method lexical function
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• no-next-method lexical function
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: type slot option
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: type slot option
  • From: kempf@Sun.COM
• Re: documentation slot option
  • From: kempf@Sun.COM
• Re: generic-function special form
  • From: kempf@Sun.COM
• Re: no-next-method lexical function
  • From: kempf@Sun.COM
• Re: symbol-class is bad name
  • From: kempf@Sun.COM
• no-applicable-method
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: symbol-class is bad name
  • From: Gregor.pa@Xerox.COM
• Re: no-next-method lexical function
  • From: Gregor.pa@Xerox.COM
• Re: no-applicable-method
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: no-applicable-method
  • From: Gregor.pa@Xerox.COM
• No-applicable-method
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Initialization
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: symbol-class is bad name
  • From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
• symbol-class is bad name
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• no-applicable-method
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Initialization Names
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: no-applicable-method
  • From: kempf@Sun.COM
• no-next-method | no-applicable-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Initialization
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Sun Opposition To Chapter 3 Hereby Tendered
  • From: Gregor.pa@Xerox.COM
• Re: no-next-method | no-applicable-method
  • From: Gregor.pa@Xerox.COM
• Re: symbol-class is bad name
  • From: Gregor.pa@Xerox.COM
• Initialization-names
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: symbol-class is bad name
  • From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
• Re: type slot option
  • From: Gregor.pa@Xerox.COM
• Re: generic-function special form
  • From: Gregor.pa@Xerox.COM
• Re: documentation slot option
  • From: Gregor.pa@Xerox.COM
• Re: No-applicable-method
  • From: kempf@Sun.COM
• Initialization Names
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Initialization Names
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Initialization Names
  • From: Gregor.pa@Xerox.COM
• Re: Initialization Names
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: documentation slot option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: type slot option
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: symbol-class is bad name
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Sun Opposition To Chapter 3 Hereby Tendered
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: generic-function special form
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: no-next-method | no-applicable-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• "Written Responses" to CLOS 88-002: SETF Functions
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Plan
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Plan Comments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• dealing with 1+2 comments
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Re: Sun Opposition To Chapter 3 Hereby Tendered
  • From: kempf@Sun.COM
• Re: Reinitialization: check-initargs
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Reinitialization: check-initargs
  • From: kempf@Sun.COM
• Re: symbol-class is bad name
  • From: Bobrow.pa@Xerox.COM
• Re: Sun Opposition To Chapter 3 Hereby Tendered
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Plan
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Plan Comments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Question about discarded slots
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Plan Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• "Written Responses" to CLOS 88-002: SETF Functions
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Plan Comments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• (setf find-method)
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Find-method
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Plan Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Plan Comments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Plan Comments
  • From: Gregor.pa@Xerox.COM
• (setf find-method)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Plan Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Find-method
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Find-method
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Plan Comments
  • From: Gregor.pa@Xerox.COM
• Re: Plan Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Plan Comments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Plan Comments
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Plan Comments
  • From: Gregor.pa@Xerox.COM
• :documentation
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• check-keyword-arguments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Comments on MOP
  • From: mcvax!delphi!chicca@uunet.UU.NET (M.R. Boscotrecase)
• :documentation
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Re: :documentation
  • From: kempf@Sun.COM
• :documentation
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: :documentation
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Check-keyword-arguments
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: Check-keyword-arguments
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: :documentation
  • From: Gregor.pa@Xerox.COM
• Re: :documentation
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: :documentation
  • From: Gregor.pa@Xerox.COM
• Chapter 1
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Check-keyword-arguments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Chapter 2
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• CLOS document numbers for June meeting
  • From: Jan Zubkoff <edsel!jlz@labrea.stanford.edu>
• Re: check-keyword-arguments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• [no subject]
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Comments on new draft chapter 1 (dated May 13 20:53)
  • From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
• Comments on new draft chapter 2 (dated May 16 15:09)
  • From: "David A. Moon" <MOON@AI.AI.MIT.EDU>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Mlynarik's comments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Comments on new draft chapter 1 (dated May 13 20:53)
  • From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
• Comments on new draft chapter 1 (dated May 13 20:53)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• check-keyword-arguments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on current state of Initialization.
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• define-method-combination
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on current state of Initialization.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• define-method-combination
  • From: Richarrd MLYnaRIk <Mly@AI.AI.MIT.EDU>
• More Check-Keyword-Arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Define-Method-Combination
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• check-keyword-arguments etc.
  • From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
• check-keyword-arguments
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Chapter 1
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Method Objects are not Functions
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: check-keyword-arguments
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Re: define-method-combination
  • From: kempf@Sun.COM
• Re: check-keyword-arguments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• define-method-combination
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: define-method-combination
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• check-keyword-arguments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Comments on current state of Initialization.
  • From: Jon L White <edsel!jonl@labrea.stanford.edu>
• Re: Mlynarik's comments
  • From: Gregor.pa@Xerox.COM
• Callable Methods
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Re: Method Objects are not Functions
  • From: Gregor.pa@Xerox.COM
• Some comments on ch.2.
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• Re: Symbol-Macrolet
  • From: cperdue@Sun.COM (Cris Perdue)
• Symbol-Macrolet
  • From: gls@Think.COM
• Symbol Macrolet
  • From: Scott.Fahlman@B.GP.CS.CMU.EDU
• Re: Symbol-Macrolet
  • From: Rabin.pa@Xerox.COM
• with-added-methods
  • From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
• [David N Gray <Gray@DSG>: making structures]
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• Compile-file environment
  • From: Patrick H Dussud <DUSSUD@Jenner.csc.ti.com>
• SYMBOL-MACROLET-UTILITY
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• which functions should be generic?
  • From: Masinter.pa@Xerox.COM
• Re: which functions should be generic?
  • From: kempf@Sun.COM
• which functions should be generic?
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: which functions should be generic?
  • From: Warren Harris <harris%hplwhh@hplabs.HP.COM>
• Re: which functions should be generic?
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• The Law of Demeter
  • From: Dick Gabriel <RPG@sail.stanford.edu>
• CLOS Workshop
  • From: Gregor.pa@Xerox.COM
• putting CLOS objects in binfiles
  • From: jrose@Sun.COM (John Rose)
• putting CLOS objects in binfiles
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: putting CLOS objects in binfiles
  • From: Bobrow.pa@Xerox.COM
• Re: putting CLOS objects in binfiles
  • From: kempf@Sun.COM
• lambda list congruence
  • From: goldman@vaxa.isi.edu
• putting CLOS objects in binfiles
  • From: jrose@Sun.COM (John Rose)
• where I'm going, etc.
  • From: Sonya E. Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• declare in with-slots
  • From: Gregor.pa@Xerox.COM
• RE: decalre in with-slots
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• RE: declare in with-slots
  • From: David N Gray <Gray@DSG.csc.ti.com>
• declare in with-slots
  • From: Patrick Dussud <edsel!dussud@labrea.stanford.edu>
• Re: declare in with-slots
  • From: kempf@Sun.COM
• Re: declare in with-slots
  • From: David N Gray <Gray@DSG.csc.ti.com>
• declare in with-slots
  • From: Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>
• Re: declare in with-slots
  • From: kempf@Sun.COM
• Re: declare in with-slots
  • From: David N Gray <Gray@DSG.csc.ti.com>
• description language classes & the Meta-Object Protocol
  • From: jrose@Sun.COM (John Rose)
• Re: description language classes & the Meta-Object Protocol
  • From: Gregor.pa@Xerox.COM
• Re: declare in with-slots
  • From: Gregor.pa@Xerox.COM
• Re: declare in with-slots
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• Re: declare in with-slots
  • From: kempf@Sun.COM
• Re: declare in with-slots
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• symbol-macrolet-semantics, symbol-macrolet-utility
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• first part of mop
  • From: Patrick Dussud <dussud@lucid.com>
• Re: first part of mop
  • From: Gregor.pa@Xerox.COM
• Fairfax Meeting
  • From: kempf@Sun.COM
• Issue: SYMBOL-MACROLET-DECLARE (version 1)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
  • From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
• Issue: SYMBOL-MACROLET-DECLARE (version 1)
  • From: Patrick Dussud <dussud@lucid.com>
• call-next-method and arguments to :before and :after methods
  • From: jrose@Sun.COM (John Rose)
• call-next-method and arguments to :before and :after methods
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-next-method and arguments to :before and :after methods
  • From: masinter.pa@Xerox.COM
• Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
  • From: masinter.pa@Xerox.COM
• Issue: SYMBOL-MACROLET-DECLARE (version 1)
  • From: Patrick Dussud <dussud@lucid.com>
• metaobject protocol (description languages)
  • From: jrose@Sun.COM (John Rose)
• Issue: DEFINE-OPTIMIZER
  • From: jrose@Sun.COM (John Rose)
• Q about CLOS
  • From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: Warren Harris <harris%hplwhh@hplabs.hp.com>
• Re: Q about CLOS
  • From: Gregor.pa@Xerox.COM
• Re: Issue: EVAL-OTHER (Version 2)
  • From: Brad Miller <miller@CS.ROCHESTER.EDU>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: masinter.pa@Xerox.COM
• CLOS analogue to TYPEP and SUBTYPEP
  • From: Eric Benson <eb@lucid.com>
• Re: CLOS analogue to TYPEP and SUBTYPEP
  • From: Gregor.pa@Xerox.COM
• CLOS Spec Chapters 1 & 2
  • From: Tim Koschmann <KOSCHMANN@SUMEX-AIM.Stanford.EDU>
• Re: CLOS Spec Chapters 1 & 2
  • From: Gregor.pa@Xerox.COM
• Issue: EVAL-OTHER (Version 2)
  • From: Jon L White <jonl@lucid.com>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: Brad Miller <miller@CS.ROCHESTER.EDU>
• Re: Issue: EVAL-OTHER (Version 2)
  • From: masinter.pa@Xerox.COM
• Standard-objects in quoted constants
  • From: cperdue@Sun.COM (Cris Perdue)
• Standard-objects in quoted constants
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Standard-objects in quoted constants
  • From: cperdue@Sun.COM (Cris Perdue)
• Standard-objects in quoted constants
  • From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
• Re: Standard-objects in quoted constants
  • From: cperdue@Sun.COM (Cris Perdue)
• How to reach Robert Kerns
  • From: cperdue@Sun.COM (Cris Perdue)
• How to reach Robert Kerns
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• How to reach Robert Kerns
  • From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
• specification request [plain text]
  • From: Flash Sheridan <flash%cs.qmc.ac.uk@NSS.Cs.Ucl.AC.UK>
• Standard-objects in quoted constants
  • From: Robert W. Kerns <RWK@f.ila.dialnet.symbolics.com>
• compile-time side effects
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• I still need help with compile-time side-effects
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• I still need help with compile-time side-effects
  • From: Jon L White <jonl@lucid.com>
• CLOS lambda-list congruence
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: CLOS lambda-list congruence
  • From: kempf@Sun.COM
• Re: CLOS lambda-list congruence
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: CLOS lambda-list congruence
  • From: kempf@Sun.COM
• Re: CLOS lambda-list congruence
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: CLOS lambda-list congruence
  • From: kempf@Sun.COM
• Suggestion Sent to CommonLoops List
  • From: David E. Wallace <wallace@hpldew>
• Compilation implications
  • From: Jon L White <jonl@lucid.com>
• Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Compilation implications
  • From: Jon L White <jonl@lucid.com>
• Re: Compilation implications
  • From: kempf@Sun.COM
• Compilation implications
  • From: Jon L White <jonl@lucid.com>
• Issue: LOAD-OBJECTS (Version 1)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: kempf@Sun.COM
• Re: Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: kempf@Sun.COM
• Re: Compilation implications
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Compilation implications
  • From: Jon L White <jonl@lucid.com>
• Re: Compilation implications
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Compilation implications
  • From: jrose@Sun.COM (John Rose)
• Compilation implications
  • From: jrose@Sun.COM (John Rose)
• Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Compilation implications
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Compilation implications
  • From: Jon L White <jonl@lucid.com>
• MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: jrose@Sun.COM (John Rose)
• MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: David N Gray <Gray@DSG.csc.ti.com>
• MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: Eric Benson <eb@lucid.com>
• MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: Eric Benson <eb@lucid.com>
• Re: MAKE-LOAD-FORM can handle circularities [was Compilation implications]
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Issue: LOAD-OBJECTS (Version 2)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issue: LOAD-OBJECTS (Version 2)
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Issue: LOAD-OBJECTS (Version 2)
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Issue: LOAD-OBJECTS (Version 2)
  • From: jrose@Sun.COM (John Rose)
• DEFMETHOD compile-time processing
  • From: David N Gray <Gray@DSG.csc.ti.com>
• DEFMETHOD compile-time processing
  • From: Patrick Dussud <dussud@lucid.com>
• DEFMETHOD compile-time processing
  • From: jrose@Sun.COM (John Rose)
• Re: DEFMETHOD compile-time processing
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• DEFMETHOD compile-time processing
  • From: Patrick Dussud <dussud@lucid.com>
• Re: DEFMETHOD compile-time processing
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Issue: FUNCTION-NAME (Version 1)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Issue: FUNCTION-NAME (Version 1)
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Issue: FUNCTION-NAME (Version 1)
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• Issue: FUNCTION-NAME (Version 1)
  • From: Gregor.pa@Xerox.COM
• editorial comments on chapter 3
  • From: David N Gray <Gray@DSG.csc.ti.com>
• classes and environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• chapter 3 comments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Issue: FUNCTION-NAME (Version 1)
  • From: jrose@Sun.COM (John Rose)
• issue SYMBOL-MACROLET-SEMANTICS
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• issue SYMBOL-MACROLET-SEMANTICS
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• I/O generic functions
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: I/O generic functions
  • From: Warren Harris <harris%hplwhh@hplabs.hp.com>
• Re: I/O generic functions
  • From: Sonya Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• I/O generic functions
  • From: Mike McMahon <MMcM@STONY-BROOK.SCRC.Symbolics.COM>
• omissions from chapter 3
  • From: David N Gray <Gray@DSG.csc.ti.com>
• local generic functions
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: issue MACRO-ENVIRONMENT-EXTENT, version 1
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• CLOS Mailing List
  • From: foote@p.cs.uiuc.edu (Brian Foote)
• effective methods question
  • From: David N Gray <Gray@DSG.csc.ti.com>
• DEFSTRUCT and DEFCLASS
  • From: David N Gray <Gray@DSG.csc.ti.com>
• CLOS questions
  • From: David N Gray <Gray@DSG.csc.ti.com>
• effective methods question
  • From: Patrick Dussud <dussud@lucid.com>
• Comments on metaobject draft 10
  • From: David Moon <moon@scrc-pegasus>
• CLOS questions
  • From: Patrick Dussud <dussud@lucid.com>
• Issue MACRO-ENVIRONMENT-EXTENT
  • From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
• Issue CONSTANT-COMPILABLE-TYPES
  • From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
• CLOS defining macros & compilation
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: CLOS defining macros & compilation
  • From: kempf@Sun.COM
• CLOS defining macros & compilation
  • From: Patrick Dussud <dussud@lucid.com>
• Re: CLOS defining macros & compilation
  • From: kempf@Sun.COM
• Re: CLOS defining macros & compilation
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: CLOS defining macros & compilation
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: CLOS defining macros & compilation
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• remote environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• CLOS defining macros & compilation
  • From: Gregor.pa@Xerox.COM
• Issue CONSTANT-COMPILABLE-TYPES
  • From: Jon L White <jonl@lucid.com>
• Re: CLOS defining macros & compilation
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: Comments on metaobject draft 10
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Comments on metaobject draft 10
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: CLOS questions
  • From: David N Gray <Gray@DSG.csc.ti.com>
• CLOS questions
  • From: Patrick Dussud <dussud@lucid.com>
• remote environments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: remote environments
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• macroexpansions of the user interface macros
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• macroexpansions of the user interface macros
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issue MACRO-ENVIRONMENT-EXTENT
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Issue: LOAD-OBJECTS (Version 2)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issue: LOAD-OBJECTS (Version 2)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issue: LOAD-OBJECTS (Version 3)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• issue CLOS-MACRO-COMPILATION
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• issue CLOS-MACRO-COMPILATION
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• issue CLOS-MACRO-COMPILATION, version 1
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• class FUNCTION etc.
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: issue CLOS-MACRO-COMPILATION, version 1
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Issue MACRO-ENVIRONMENT-EXTENT
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: issue CLOS-MACRO-COMPILATION, version 1
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: issue CLOS-MACRO-COMPILATION, version 1
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: issue CLOS-MACRO-COMPILATION, version 1
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: remote environments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: remote environments
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Issue: LOAD-OBJECTS (Version 3)
  • From: Richard P. Gabriel <rpg@lucid.com>
• Re: Issue: LOAD-OBJECTS (Version 3)
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Issue: LOAD-OBJECTS (Version 3)
  • From: Richard P. Gabriel <rpg@lucid.com>
• Re: remote environments
  • From: Gregor.pa@Xerox.COM
• Re: remote environments
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: remote environments
  • From: Gregor.pa@Xerox.COM
• Re: remote environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: remote environments
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Issue: LOAD-OBJECTS (Version 3)
  • From: jrose@Sun.COM (John Rose)
• Understanding Method Combination.
  • From: James Rice <rice@sumex-aim.stanford.edu>
• Re: Issue: LOAD-OBJECTS (Version 3)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Understanding Method Combination.
  • From: Gregor.pa@Xerox.COM
• Re: Understanding Method Combination.
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Issue: LOAD-OBJECTS (Version 3)
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Re: Issue: LOAD-OBJECTS (Version 3)
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: Understanding Method Combination.
  • From: Gregor.pa@Xerox.COM
• Re: Understanding Method Combination.
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Compile Time Class Creation (was: remote environments)
  • From: kempf@Sun.COM
• Issue STREAM-DEFINITION-BY-USER (V1)
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Implementation of CLOS
  • From: BRANDIMARTE%ITOPOLI1.BITNET@Forsythe.Stanford.EDU
• issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: Patrick Dussud <dussud@lucid.com>
• Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: issue COMPILE-ENVIRONMENT-CONSISTENCY
  • From: Gregor.pa@Xerox.COM
• [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]
  • From: masinter.pa@Xerox.COM
• [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]
  • From: kempf@Sun.COM
• Re: [kempf%Sun:COM:Xerox: CLOS Slot Subclassing Rule Violates Contravariance]
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• Chap 3 question: Class of allocated instances.
  • From: Jon L White <jonl@lucid.com>
• Chap 3 question: Class of allocated instances.
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Chap 3 question: Class of allocated instances.
  • From: Patrick Dussud <dussud@lucid.com>
• Re: DEFSTRUCT and DEFCLASS
  • From: David N Gray <Gray@DSG.csc.ti.com>
• DELPHI CLOS
  • From: Wilhelm Burger <K320440%AEARN.BITNET@Forsythe.Stanford.EDU>
• joining mailing list
  • From: unido!slpfs1!tartaros!sz@uunet.UU.NET (Peter Szabo)
• CLOS Workshop
  • From: Gregor.pa@Xerox.COM
• DEFINE-METHOD-COMBINATION issues
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• editorial correction to CLOS stuff
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• editorial correction to CLOS stuff
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: editorial correction to CLOS stuff
  • From: Gregor.pa@Xerox.COM
• DEFINE-METHOD-COMBINATION issues
  • From: Patrick Dussud <dussud@lucid.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Random metaclasses for CL types
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Random metaclasses for CL types
  • From: Patrick Dussud <dussud@lucid.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Random metaclasses for CL types
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Random metaclasses for CL types
  • From: Patrick Dussud <dussud@lucid.com>
• re: Random metaclasses for CL types
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• re: Random metaclasses for CL types
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• re: Random metaclasses for CL types
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• re: Random metaclasses for CL types
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• Random metaclasses for CL types
  • From: Patrick Dussud <dussud@lucid.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• re: Random metaclasses for CL types
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Random metaclasses for CL types
  • From: Gregor.pa@Xerox.COM
• Re: Random metaclasses for CL types
  • From: kempf@Sun.COM
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Re: Random metaclasses for CL types
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• issue CLOS-MACRO-COMPILATION
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• FLAVOR-CLASS, and Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• issue COMPILE-ENVIRONMENT-CONSISTENCY, version 6
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• FLAVOR-CLASS, and Random metaclasses for CL types
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• FLAVOR-CLASS, and Random metaclasses for CL types
  • From: Jon L White <jonl@lucid.com>
• Re: issue CLOS-MACRO-COMPILATION, version 4
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• Re: issue CLOS-MACRO-COMPILATION, version 4
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• SYMBOL-MACROLET
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• SYMBOL-MACROLET
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• 2nd CLOS Workshop
  • From: Gregor.pa@Xerox.COM
• re: DEFMETHOD with no required args?
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• re: call-next-method incoherency
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• DEFMETHOD with no required args?
  • From: David N Gray <Gray@DSG.csc.ti.com>
• re: DEFMETHOD with no required args?
  • From: Gregor.pa@Xerox.COM
• call-next-method incoherency
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-next-method incoherency
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: call-next-method incoherency
  • From: Gregor.pa@Xerox.COM
• Re: call-next-method incoherency
  • From: Danny Bobrow <Bobrow.pa@Xerox.COM>
• call-next-method incoherency
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-next-method incoherency
  • From: Gregor.pa@Xerox.COM
• call-next-method incoherency
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• DOCUMENTATION and DEFCLASS
  • From: David N Gray <Gray@DSG.csc.ti.com>
• method combination objects
  • From: David N Gray <Gray@DSG.csc.ti.com>
• method combination objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• DOCUMENTATION and DEFCLASS
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: method combination objects
  • From: David N Gray <Gray@DSG.csc.ti.com>
• Re: method combination objects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• call-next-method
  • From: Gail Zacharias <gz@spt.entity.com>
• call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-next-method
  • From: Gregor.pa@Xerox.COM
• Re: call-next-method incoherency
  • From: Gregor.pa@Xerox.COM
• Re: call-next-method incoherency
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• CLOS changes
  • From: David N Gray <Gray@DSG.csc.ti.com>
• MOP slot definition questions
  • From: David N Gray <Gray@DSG.csc.ti.com>
• CLOS changes
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Re: call-next-method
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• define-method-combination examples
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• define-method-combination examples
  • From: Patrick Dussud <dussud@lucid.com>
• ENSURE-CLASS-USING-CLASS
  • From: David N Gray <Gray@DSG.csc.ti.com>
• ENSURE-CLASS-USING-CLASS
  • From: Patrick Dussud <dussud@lucid.com>
• Re: ENSURE-CLASS-USING-CLASS
  • From: David N Gray <Gray@DSG.csc.ti.com>
• [no subject]
  • From: Guest Login ID <guest@oberon.usc.edu>
• Draft 88-003
  • From: DongHyeon Lee <dhlee@csd.kaist.ac.kr>
• Query on ISSUE: LOAD-OBJECTS
  • From: Jon L White <jonl@lucid.com>
• Query on ISSUE: LOAD-OBJECTS
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Test Message
  • From: loeffler@daystar.aca.mcc.com (David Loeffler)
• CLX toolkit and/or CLUE Contact "classes/libraries"
  • From: aseem@atc.boeing.com
• names of classes in the standard?
  • From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
• names of classes in the standard?
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• function-keywords meets &rest
  • From: Gregor.pa@Xerox.COM
• function-keywords meets &rest
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• TEST message from Postmaster
  • From: Common-Lisp-Request@mcc.com
• method combinations changing
  • From: Gregor.pa@Xerox.COM
• method combinations changing
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• method combinations changing
  • From: Patrick Dussud <dussud@lucid.com>
• method combinations changing
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• generic-function, generic-flet, generic-labels
  • From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
• re: generic-function, generic-flet, generic-labels
  • From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
• function-keywords meets &rest
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Proposed de facto standard subset of metaobjects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Proposed de facto standard subset of metaobjects
  • From: David Gray <gray@lucid.com>
• Proposed de facto standard subset of metaobjects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Proposed de facto standard subset of metaobjects
  • From: David Gray <gray@lucid.com>
• Proposed de facto standard subset of metaobjects
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• MOP
  • From: Sonya Keene <skeene@STONY-BROOK.SCRC.Symbolics.COM>
• Call for contribution: A "CLOS Report" Publication
  • From: Andreas Paepcke <paepcke@hplap.hpl.hp.com>
• Including my name in your mailing address
  • From: liu@demon.siemens.com (Peiya Liu)
• Re: Call for contribution: A "CLOS Report" Publication
  • From: Gregor.pa@Xerox.COM
• Lazy error signaling?
  • From: Jon L White <jonl@lucid.com>
• Lazy error signaling?
  • From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
• Lazy error signaling?
  • From: Patrick Dussud <dussud@lucid.com>
• Lazy error signaling?
  • From: kab@charon.MIT.EDU (Kim A. Barrett)
• Lazy error signaling?
  • From: Patrick Dussud <dussud@lucid.com>
• Lazy error signaling?
  • From: kab@charon.MIT.EDU (Kim A. Barrett)
• Lazy error signaling?
  • From: Patrick Dussud <dussud@lucid.com>
• May Day PCL won't compile in HP Lucid 3.0
  • From: Steve Strassmann <straz@media-lab.media.mit.edu>