HDTenEightyP/NetNews huggingface dataset:
From: dinitz@tekbspa.UUCP
Subject: Re: using mop to remove instance variables
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 9 Sep 1992 04:09:10 GMT

Bryan,

 You might try this:

(defclass complex ()
 ((real-part :accessor real-part)
  (imag-part :accessor imag-part)))

(defclass real (complex)
 ((imag-part :allocation :class
	     :initform 0)))

 I haven't tested it, but I imagine (pun intended) that the class
allocation on the subclass slot will override the instance allocation
on the parent class.  The IMAG-PART accessor should still return 0,
but instances of REAL won't allocate space for a slot value.  Instead,
the first time you create an instance of REAL, the class slot will be
initialized to 0.

 Your mileage may vary depending on the implementation. 

 But do notice that I didn't have to use the MOP.


 Of course, you have already noted that one would never handle complex
numbers this way in CL.  CL already has convenient facilities for
complex numbers.

 But suppose you really did want to model complex numbers with CLOS (I
remember a paper at OOPSLA-86 that modelled such algebraic constructs
in SmallTalk).  Wouldn't it make more sense to work constructively,
rather than subtractively?  For example:

;;; REAL is a built-in type.
(defmethod imag-part ((r real))
   0)

(defmethod real-part ((r real))
   r)

(defclass complex ()
 ((real-part :accessor real-part)
  (imag-part :accessor imag-part)))

 Once again, notice that I didn't have to use the MOP.


 Be sure you don't fall into the trap of thinking generic functions
must be anchored in classes.  CLOS goes beyond that -- generic
functions are independent of any particular class, and methods can
specialize on any class or type.

 Sometimes it takes effort to avoid confusing the class hierarchy with
an is-a hierarchy.  Although class inheritance can often be a good
medium to model is-a relationships (because CL's convenient type-of
mechanism), you may not always want to do this.  There are other ways
to use class structure inheritance.


 -Rick

*-------------------------------*
| Copyright 1992, Rick Dinitz	|
| dinitz@tss.com		|
*-------------------------------*


>I have an application where it is redundant to store a value for an
>instance variable in a specialization of a class. I'll use numbers as
>as an analogy (not that one would do this with numbers in common lisp):
>
>One might have a class called complex-number that has two instance
>variables real-part and imaginary part. A second class real-number
>would be a specialization of complex-number but doesn't need to store
>a 0 in the imaginary part. One could simply write an accessor that
>always returns 0.
>
>Has anyone used the MOP to allow a class such as real-number to not
>have to store the unwanted instance variables? I'd love to have
>someone send me an example so that I can avoid doing the work myself.
From: lgm@cbnewsc.ATT.COM (lawrence.g.mayka)
Newsgroups: comp.lang.clos,comp.object
Subject: Re: Looking for information on CLOS based distributed object systems
Date: 6 Sep 92 15:22:12 GMT
Organization: AT&T Bell Laboratories

In article <01050159.cgf6gc@devlab.IISA.COM> kpt@IISA.COM (Kevin P. Tyson) writes:
   I'm looking for information on CLOS based distributed object systems.
   It seems, from what little information I have available, that every
   O-O language except CLOS has been used to develop such systems.  Is
   this true or have I missed something?  If it is true then what has
   lead to this state of affairs?

Take a look at the paper our supervisor presented at the 1990
International Switching Symposium in Stockholm, "Object Oriented
Software Technologies Applied to Switching System Architectures and
Software Development Processes."  Of course, back then we programmed
in New Flavors, which is essentially a subset of draft-ANSI CLOS.

        Lawrence G. Mayka
        AT&T Bell Laboratories
        lgm@iexist.att.com

Standard disclaimer.
From: lange@lanai.cs.ucla.edu (Trent Lange)
Newsgroups: comp.lang.clos
Subject: Alternative specializer types
Date: 8 Sep 92 01:09:40 GMT
Organization: UCLA Artificial Intelligence Laboratory

In an application I'm developing, it would be very useful to allow my
methods to have specializers different than the standard class or eql
specializers, but it's not clear whether the AMOP supports it.  In
particular, I would like to have a class of methods that can use
"AND" specializers, as in:

(defmethod foo ((self (and class1-mixin class2-mixin))) ...)

I need this because class1-mixin and class2-mixin can be used
independently of each other, but when used together require a
completely different algorithm for foo.  I could, of course, create
a class1-and-class2-mixin class that inherits both and does what is
necessary.  However, I'm trying to design my class hierarchy so that
users can build their classes out of whatever mixins they need, without
having to worry about their potential interdependencies (e.g. knowing
they have to include a class1-and-class2-mixin).

From what I can tell, the AMOP basically mentions nothing at all
about using these kind of alternative specializers.  It seems like
it *does* support it, or is close to supporting it, in that one would
only have to specialize COMPUTE-APPLICABLE-METHODS and
COMPUTE-APPLICABLE-METHODS-USING-CLASSES for the new method class
to work with the new specializer type.

My worry is that the specification of CLOS and the AMOP only
mentions specializers as being class or eql specializers.  In fact,
the text for DEFMETHOD on p. 839 of Steele Vol. 2 explicitly says:
"A parameter specializer name is a symbol that names a class or
(eql eql-specializer-form)."

Does this rule out what I want to do?  I can easily make the change
to support alternative specializers for the next version of July 92 PCL,
but is it supported by the AMOP (and other implementations)?

- Trent Lange
  lange@cs.ucla.edu
Newsgroups: comp.lang.clos
From: kramer@cs.toronto.edu (Bryan M Kramer)
Subject: Re: Re: using mop to remove instance variables 
In-reply-to: Your message of "Wed, 09 Sep 92 14:09:10 EDT."
             <9209091806.AA09645@tss.com> 
Date: 10 Sep 92 20:17:40 GMT

CACM 35(8) Aug. 92, p 128 has an interesting article dealing with the
issues in two different views of specialization, i.e.

conceptual  natural -> integer -> rational -> real -> complex
(-> means specializes)
vs

program oriented where Float, Fraction, and Integer all specialize
Number.

|Bryan M. Kramer, Ph.D.	      416-978-7330, fax 416-978-1455|
|Department of Computer Science, University of Toronto      |
|6 King's College Road, Room 283E			    |
|Toronto, Ontario, Canada      M5S 1A4                      |
Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: Example of boundary case (sort of long)
Organization: UCLA Artificial Intelligence Laboratory
Date: Wed, 9 Sep 92 01:53:03 GMT

In article <65489@cup.portal.com> Thomas_E_Morgan@cup.portal.com writes:
>
>>I'd like to try and help, but I don't understand just what it is you are
>>trying to do.  For one thing, I can't understand what you mean by "slot
>>storage for metaclass instances."  If you can say some more about this
>>that would be good.  
>
>Here's an edited dribble of what I was trying in May '90; the things to notice
>are that my employee's names and so forth are being versioned, but so is 
>the fact that employees have sexes, names etc,  at all.  For reasons that
>Trent has pointed out, this doesn't even get off the ground in July 92 PCL,
>and as I asked earlier, I'm not even sure that it should. 
>
>? (defclass versioned-person (versioned-object))
>  ((sex :accessor sex :initarg :sex)
>   (name :accessor name :initarg :name))
>   (age :accessor age :initarg :age)))
>  (:metaclass standard-versioned-class)))
>[...]

The problem that Tom was having in July 92 PCL is that all of his classes
with metaclass standard-versioned-class use a non-standard slot allocation
scheme (that keeps track of his versions as shown in his example).
This in itself is fine, except that his metaclass standard-versioned-class
has itself as a metaclass -- i.e. all of the slots of his class metaobjects
(e.g. versioned-person, an instance of standard-versioned-class) have
a non-standard :allocation themselves.

In other words, his metaclass standard-versioned-class changes the
:allocation of *all* of the class slots (e.g. direct-superclasses,
direct-slots, etc) of his standard-versioned-class class metaobjects
(e.g. versioned-persion) from their standard :instance allocation to his
:versioned allocation.  This also, of course, means that he is implicitly
(hoping) that the built-in CLOS primary reader generic-functions change
correctly for the class (e.g. class-direct-super-classes, class-direct-slots),
since they have to read from his :versioned allocation slots rather
than the expected :instance allocation.

The question is whether this is "legal" in the AMOP.  I see no reason why
it couldn't be done in PCL (PCL's class metaobject readers use standard
readers, so appropriate changes to slot-value-using-class should do the
trick for him).  One would just have to be very careful to get the order
of the class metaobjects slots' initializations done correctly (as I
pointed out in a previous post).

However, changing the internal allocations of the class metaobject slots
like he is doing might not be portable in terms of the AMOP.  The strictures
against defining methods on SHARED-INITIALIZE for class specializers
(p. 196 of the AMOP) might be read that way.  However, it is not clear.
This, I believe, is the basic question.

- Trent Lange

-- 
*************************************************************************
*   UCLA:  The Greatest School in the History of College Basketball.    *
*************************************************************************
Newsgroups: comp.lang.clos
From: ajw@Think.COM (Andy Wilson)
Newsgroups: comp.lang.clos,comp.object
Subject: Re: Looking for information on CLOS based distributed object systems
Date: 4 Sep 92 22:55:42 GMT
Article-I.D.: early-bi.188pheINNp7m
Distribution: world
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: custard.think.com

In article <01050159.cgf6gc@devlab.IISA.COM>, kpt@IISA.COM (Kevin P. Tyson) writes:
|> I'm looking for information on CLOS based distributed object systems.
|> It seems, from what little information I have available, that every
|> O-O language except CLOS has been used to develop such systems.  Is
|> this true or have I missed something?  If it is true then what has
|> lead to this state of affairs?
|> 

This is certainly not true,  as a couple of years ago I worked on a distributed
message processing system for banks which was written in CLOS.

|> Thanks in advance,
|> Kevin P. Tyson
|> (kpt@iisa.com)
Xref: sparky comp.lang.clos:798 comp.object:3496
From: iac!simpson@uunet.uu.net (Scott Simpson)
Newsgroups: comp.lang.clos,comp.object
Subject: Re: Looking for information on CLOS based distributed object systems
Date: 10 Sep 92 03:30:25 GMT
Reply-To: iac!simpson@uunet.uu.net
Followup-To: comp.lang.clos
Organization: Investment Technology Group, Culver City, CA

>In article <01050159.cgf6gc@devlab.IISA.COM>, kpt@IISA.COM (Kevin P. Tyson) writes:
> I'm looking for information on CLOS based distributed object systems.
> It seems, from what little information I have available, that every
> O-O language except CLOS has been used to develop such systems.  Is

Not true. Call Itasca Systems in Minneapolis, Minnesota.  I believe
the Itasca OODB which is written in Common Lisp and supports CL has
distributed persistence.  The Itasca OODB is derived from the well
known Orion prototype at the now defunct MCC.  I'll leave the research
for finding Itasca's phone number and papers on Orion up to the
reader.


-- 
Scott Simpson, Investment Technology Group, iac!simpson@uunet.uu.net
From: Thomas_E_Morgan@cup.portal.com
Newsgroups: comp.lang.clos
Subject: Re: At the boundary of the MOP?
Date: Mon,  7 Sep 92 11:17:21 PDT
Organization: The Portal System (TM)
Distribution: world

(I was asking for opinions on how far teh MOP could be pushed):

>>I have been doing some work which involves taking over the
>>slot storage for metaclass instances.  The purpose in doing
>>so is to experiment with a fully versioned environment, where
>>the values of slots, as well as the slots hemselves are 
>>versioned.  Behaviors get version too, for that
>>matter. 

Harely Davies replies:

>I think this is exactly the sort of extension that a MOP should
>allow.  It would be sad if this is impossible using the CLOS MOP.
>Perhaps some more detail on why you think this may never work would
>help.  I know that at least one of our clients is working on something
>similar using the TELOS MOP, and has not yet encountered any
>fundamental difficulties.

Well, I'm still stalking the problem, but the upshot is that taking over
the storage for the slots of the class itself is tripping over an
optimization that avoids re-running initforms, by keeping a copy of a 
partially initialized instance around.  The optimization runs 
shared-initialize only for 'vanilla' slots, but my take over of 
storage means there are no 'vanilla' slots; then an :after method
on shared-initialize for classes gets upset, since several vital 
slots haven't been initialized.

I am sure I *can* make this work, but am also equally sure that this is
an example of a need for a better way to specify what's happening here.

For example, to take a silly extreme, I certainly couldn't take over 
slot storage for the class itself and start giving back random values and 
expect that to work.

But how about setting up slot storage that works in 'versions'; starting
from some consistent point, all the setf's are captured in a 'version', which 
may get rolled back to that prior point.  Should that be expected to work?
How can I tell?  How can the MOP implementor, who is working on 
some caching optimization know that I may be doing something of the sort?

   ...Tom M
From: roemer@ikki.informatik.rwth-aachen.de (Angela Roemer)
Newsgroups: comp.lang.clos
Subject: AKCL/PCL for DOS works fine, but ...
Date: 8 Sep 92 17:08:32 GMT
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen


 
Hello,
 
 I've just successfully compiled PCL August-28 on top of the
 beta AKCL-608c for DOS.
 
 Although not tested extensively, it seems to work without any problems.
 The speed on a 486/33MHz/16MB RAM is comparable to that of the
 SUN Sparc I usually work with. On a 386/33MHz/8MB, it's terribly 
 slow.
 
 With the beta version of AKCL comes the go32 DOS-extender (1.06)
 from DJ. I think there must be a newer (probably faster) version.
 Furthermore, the latest AKCL is version 615.
 
 Has anybody already tried building AKCL/PCL for DOS using newer 
 versions of AKCL and/or gcc?
 
 
Angela
 

-- 
----------------------------------------------------------------------
Angela Roemer
e-mail: roemer@pool.informatik.rwth-aachen.de
----------------------------------------------------------------------
Newsgroups: comp.lang.clos,comp.lang.lisp
From: flan@starling.wustl.edu (Ian Flanigan)
Subject: Looking For CLOS & MOP & *Multitasking*
Keywords: CLOS, MOP, multitasking, free, public domain
Organization: Washington University, School of Engineering, St. Louis MO
Date: Sun, 13 Sep 1992 23:37:56 GMT

Hi,
	I'm looking for a version of Lisp with CLOS, MOP, _and_ a multitasking  
facility.
	To be more specific, I'd like a full CLOS.  I've looked at the Closette  
from "The Art of the Metaobject Protocol" and it has too many limitations.  For  
example, I want class redefinition, method redefinition, forward-referenced  
superclasses, deductive construction of generic functions, re-definable method  
combination, eql specializers, and :class slot allocation.
	I'd like a reasonable MOP.  I want to be able to redefine the way in  
which methods are applied.  (I'd like to be able to have objects "stand in" for  
other objects and so forth.)  I'd also like to have the classes know how to  
archive themselves to disk, etc.
	I'd also like a multitasking system.  I know that Sun Common Lisp has a  
multitasking system, and I liked what I saw of it.  However their CLOS had no  
MOP, so it doesn't quite measure up.
	
	What's out there that has all this?  Is there a multitasking package  
for AKCL (PCL)?  For the CMU Common Lisp?

Thanks much.

(I will post a summary if there is any interest.)
--
Ian Flanigan		"You can never have too many napkins."

Project Zeus
Washington University in St. Louis
flan@starling.wustl.edu
Newsgroups: comp.lang.clos
From: rpg%inferno@lucid.com (Richard P. Gabriel)
Subject: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 15 Sep 1992 18:39:11 GMT

It pays to study carefully why something is successful before you
mimic it. Following the C/Unix model might seem to make sense, but we
should understand, not guess, why it succeeded. 

For example, suppose you wanted to be a successful
singer/actress/director. Looking at Barbra Streisand, you'd notice she
has a big nose and a Brooklyn accent.  Having a reverse nose job and
voice training might not work the way you want.

			-rpg-

Newsgroups: comp.lang.clos
From: kentw@bellcore.com (Kent Wittenburg)
Subject: Re: Corrections on Itasca and MCC
Followup-To: comp.lang.clos
Organization: Bellcore, Morristown, NJ
	<771@iac.uunet.uu.net>
Date: 11 Sep 92 07:30:52


   >In article <01050159.cgf6gc@devlab.IISA.COM>, kpt@IISA.COM (Kevin P. Tyson) writes:
   > I'm looking for information on CLOS based distributed object systems.
   > It seems, from what little information I have available, that every
   > O-O language except CLOS has been used to develop such systems.  Is

   Not true. Call Itasca Systems in Minneapolis, Minnesota.  I believe
   the Itasca OODB which is written in Common Lisp and supports CL has
   distributed persistence.  The Itasca OODB is derived from the well
   known Orion prototype at the now defunct MCC.  I'll leave the research
   for finding Itasca's phone number and papers on Orion up to the
   reader.

Last I knew, Itasca did not support CLOS, but rather used a home-grown
persistent object system.  Am now checking on that.

MCC is NOT defunct, although the Orion project is.

--

Kent Wittenburg
Bell Communications Research
Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 15 Sep 1992 19:06:28 GMT

> It pays to study carefully why something is successful before you
> mimic it. Following the C/Unix model might seem to make sense, but we
> should understand, not guess, why it succeeded. 

Well, maybe it's because I've never been a big user of Lisp machines,
but the way I use Lisp is fairly close to the C/Unix model.  That is,
I have some source files that I edit using a text editor (Emacs), I
have a makefile or a defsystem, and I compile the files to produce
a loadable system.  I don't live in a Lisp image that persists from
day to day.

On the other hand, I wouldn't want to go further towards C and
have to recompile and relink my system every time I make a change
and every time I want to mix in some other stuff.  So, in the
short term I do live in a Lisp world that I modify.

Most of the time this is fine.  But some people don't want to
live in the Lisp world.  They don't mind having something written
in Lisp, but they don't want to have to be in Lisp to use it.
I feel this way when I want to use Lisp to write a Unix command
I can invoke from the shell, for instance.

Unix/C is successful, and it's pretty clear by now that many
people don't want to move into Lisp instead.  They don't want
to adapt to Lisp; and they'll use Lisp only if it adapts to
their way of doing things.

In short, I think there's a case for adapting even if we don't
know _why_ Unix and C are successful; and I would probably be
somewhat happier myself if Lisp made some moves in this direction.

That said, however, I agree that we should try to figure out
why UNix and C are successful, and I'm not all that happy with
some of the things people are doing to move closer to C and Unix.
For instance, I don't want to get rid of EVAL.

-- jd
From: smh@franz.com (Steve Haflich)
Newsgroups: comp.lang.clos
Subject: Smart diplay method
Date: 16 Sep 92 01:29:39 GMT
Organization: The Ohio State University Department of Computer and Information Science


   From: raman@cs.cornell.edu (T. V. Raman)

   How do I write a print-object method for a class that neatly formats
   slot names and values one per line without having to explicitly write
   (format "..."
   (<slot-name-value> object)
   ..
   )

You should first consider the `contract' that a print-object method is
supposed to obey.  The major purpose print-object exists is so the
printer can call it to deal with user-defined objects.  Unless you can
guarantee that the method won't be called in the general case (for
instance, by specializing the method on the stream argument) then the
method shouldn't emit any newlines because that can screw up the
printer, and especially, the pretty printer, and cause them to
interact poorly with other tools in the implementation (debugger,
inspector, whatever) that rely on the behavior of the printer.

To write the code in a way that doesn't violate the contract, you need
to use the new pretty-printer directives described in CLtL2 chapter
27.  These include pprint-logical-block, pprint-newline, pprint-tab,
and pprint-indent.  You can use these either directly, or through the
format directive interface.

All this is pretty tricky if you haven't used the new printer before.
The easy part of the problem is getting your hands on the object's
slots, etc., assuming just a minimal amount of the MOP is available.
This is an approximation:

          (defmethod print-object ((x foo) s)
	    (let* ((class (class-of x))
		   (slots (clos:class-slots class))
		   (l (mapcar #'(lambda (slot)
				  (let* ((name (clos:slot-definition-name slot))
					 (boundp (slot-boundp x name))
					 (val (and boundp
						   (slot-value x name))))
				    (list name boundp val)))
			      slots)))
	      (print-unreadable-object (x s :type t :identity nil)
		(format s "~<~:@{~s: ~15:T~:[<unbound>~;~s~]~:@_~}~:>"
			l))))
Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: Functional Interfaces and CLOS Metaobject Protocols
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 10 Sep 1992 18:50:54 GMT

An interesting (at least to me), semi-philosphical question is 
this: exactly what is the constribution of the MOP?

There's talk, in the AMOP book and other places, about how a MOP
breaks down the distinction between programmers and language
designers; but the same can be said of Lisp itself.  (For an
instance of where it has been said, see McCarthy's paper in
the 1980 Lisp Conference.)

There's also some talk about the MOP letting you combine
customizability with efficiency, but that's also a goal in
plain Lisp.  It's why we have compiler macros and the like.

What we might do in ordinary Lisp is this, there would be a
set of "good primitives", new ways of doing things would be
defined as functions, and compiler macros could be used to
tell the compiler how to compile them efficiently.

Unfortunately, the "good primitives" are often missing.  (Eg,
look at all the people who want a bit more control over DEFSTRUCT.)
The main thing the MOP provides (imho) is a set of good primitives
in a certain area.  The main things it fails to provide (as yet)
is a way to tell the compiler what it needs to know.

-- jd
Newsgroups: comp.lang.clos