HDTenEightyP/NetNews huggingface dataset:
From: john@linus.mitre.org
Newsgroups: comp.lang.clos
Subject: Compiling objects (was Beginner's Question - CLOS)
Date: 26 Aug 92 07:03:08 GMT
Organization: The Ohio State University Department of Computer and Information Science

Chris (cb@maths.bath.ac.UK) writes:

    It sounds like you don't need C++ as much as a Petri net compiler
    that takes your nice object oriented specification and spits out
    fast code, like a big PROG, for example.

  I could do that, but part of the reason I started doing this was to
  show that petri-nets are a good example of something that maps well
  into object-oriented simulation.  As far as the programming of it
  goes, it is real nice to represent Places and transitions as objects
  and have the actions on them represented as methods.  However, if
  it's that much faster to compile the petri net spec into
  non-object-based code, then its pretty hard to argue that
  object-oriented simulation is a good thing.

Ah, but the code for compiling the Petri nets might be very easy to
design and write because you can distribute it like any other OO
program.  Even better, compiled and non-compiled objects can coexist.
I'm currently working on a natural language understanding system that
represents many things as different kinds of functors, and combines
them with combinators like function application and composition.  To
make it faster, each class of functor knows how to compile an instance
of that class into what is essentially a big PROG.  Also, the
combinators themselves get compiled as well.  Finally, there are
special methods on the combinators that know how to combine compiled
functors by executing the compiled code.  All of this exists on top
of, and in coexistence with, the original code for non-compiled
functors and combinators.

This was much easier to do in an OO language like CLOS.

John Burger
john@mitre.org
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 25 Aug 92 17:36:18 GMT
Article-I.D.: subnode.11102.9208251736
Organization: The Ohio State University Department of Computer and Information Science

> Consider why you implemented it in Lisp in the first place.  Because
> implementing complex applications like these is more feasible with
> Lisp/CLOS than most other languages.  

Not necessarily.  Perhaps I like Lisp or am used to it.  Maybe someone
else would feel C++ was the natural choice.  (This sort of thing does
happen.  There are lots of things I would write in Lisp that the guy
I share my office with would write in C.)  Maybe I have to justify
my use of Lisp.  Sure, maybe it takes twice as long in C++, but can
I prove this?

So I think it does matter how slow method dispatch is in Lisp.
If it's significantly slower than in C++, and known to be, then
it will be that much harder to justify my use of Lisp.

> Perhaps you might have gotten a
> program that runs twice as fast using C++, but it might have taken twice as
> long to get it working in the first place; could you have afforded to take
> that long?  (Well, you're in academia, so there may be less deadline
> pressure than in industry, so answer as if you were in industry)
> 
> You managed to speed it up significantly by converting your CLOS stuff to
> structures.  Lisp's strength is as a rapid prototyping language, and you've
> demonstrated that beautifully: consider the CLOS version to be the
> prototype.  If it was well designed, it probably wasn't all that hard to
> convert to a structure-based version once it was complete.  Lisp is good
> for incremental redesign like this.

If you have time.  Remember that you may have to justify writing one
version and then re-working it to be faster.  "Why didn't you write it
the fast way to begin with?" you will be asked.  You may also have to
argue, before the prototype is written, that CLOS is suitable, and 
efficiency may be part of the case you have to make.

-- jd
From: rharris@rdrc.rpi.edu
Newsgroups: comp.lang.clos
Subject: Re:  CLOS/PCL: ordering of methods bug
Date: 25 Aug 92 09:44:57 GMT
Article-I.D.: dice0.9208251744.AA28894
Organization: The Ohio State University Department of Computer and Information Science

There is a bug in all versions of PCL newer that March 92 PCL:

This bug affects generic functions which use dispatch dfuns, and arises
because of a bug in the proclaim-incompatible-superclasses form that
appears in methods.lisp (which in turn was "caused" by a bug in 
the definition of *built-in-classes*).

   The bug:
   >lisp
   CMU Common Lisp 16e, running on nova0.rdrc.rpi.edu
   Send bug reports and questions to your local CMU CL maintainer, or to
   cmucl-bugs@cs.cmu.edu.
   Loaded subsystems:
       Python 1.0, target SPARCstation/Sun 4
       CLOS based on PCL version:  March 92 PCL (2a)
   * (defmethod test ((x null)) nil)
   
   #<Standard-Method TEST (NULL) {700D63D}>
   * (defmethod test ((x list)) t)
   
   #<Standard-Method TEST (LIST) {70115F5}>
   * (test nil)
   Compiling LAMBDA (#:G4 #:G5): 
   Compiling Top-Level Form: 
   
   NIL
   * (test nil)
   
   T
   * (quit)
   >


The simplest patch:
(in-package :pcl)
(let ((seq (find-class 'sequence))
      (sym (find-class 'symbol)))
  (setf (class-incompatible-superclass-list seq)
	(delete sym (class-incompatible-superclass-list seq)))
  (setf (class-incompatible-superclass-list sym)
	(delete seq (class-incompatible-superclass-list sym))))


The patches to apply to the sources (if you so desire):
;in defs.lisp, in the definition of *built-in-classes*,
;change the line:
    (null       (symbol)   ()                       (symbol list sequence t)
;to:
    (null       (symbol 
		 list)     ()                       (symbol list sequence t)

;in methods.lisp, in the form that begins:
(mapc
 #'proclaim-incompatible-superclasses
;change the lines:
   (number sequence character symbol	; direct subclasses of t, but not array
    standard-object structure-object)
;to:
   (number sequence character   	; direct subclasses of t, but not array
    standard-object structure-object)   ;                         or symbol

;;; also, here is a fix for another bug (I think this bug causes no problems)
;in methods.lisp, in the definition of augment-type,
;change the line:
			    (unless (*subtypep type new-type)
;to:
			    (unless (*subtypep new-type type)


;------------------------
;if you want to look at what is happening in greater detail, use this:
(in-package :pcl)

(defvar gdn #'generate-discrimination-net)
(defun generate-discrimination-net (&rest args)
  (print (list* 'generate-discrimination-net args))
  (let ((net (apply gdn args)))
    (pprint net)(terpri)
    net))


  Richard Harris
Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 4 Sep 1992 16:14:54 GMT

> In article <j1kn6ll.objsys@netcom.com> Bob Hathaway <objsys@netcom.com> writes:
> still don't understand why people think functions in CLOS are special;
> except for their left-to-right ordering and lack of default protection for
> their arguments they're still just ordinary polymorphic functions invoked at
> run-time.  Maybe the run-time function invocation not being so commonly
> available explains why this is considered special (and is to CLOS' credit).
> But the lack of default protection means no multiple-implementations per
> type; a severe restriction that I doubt even CLOS' intercessory protocols
> can overcome.  Am I wrong here?  Can CLOS provide for the separation of
> types and classes (or any kind of multiple implementations per type)?

I'm not sure what this means.  It's certainly possible to have
a class (eg, STACK) with subclasses for different implementations
(eg, vector in one, list in another).  But in Common Lisp every class
is a type, so it's not possible to separate them unless by "type"
you mean something different than Common Lisp does.  But then I
can't tell which of the alternative definitions yoiu have in mind.
Nor do I know what you mean by "default protection".

> P.S.  Going typeless is not an acceptable answer.

Why not?  What problem will I have in pracrtice (as opposed to
theory)?

-- jd

Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: Slot access performance (was Re: Beginner's Question - CLOS)
Organization: UCLA Artificial Intelligence Laboratory
Date: Wed, 26 Aug 92 07:14:25 GMT

In article <9208260507.AA05043@kuwait.lucid> jonl%kuwait@lucid.com (Jon L White) writes:
>
>But much more importantly is to look at SLOT-VALUE in an open-codable
>context; Lucid's implementations  show almost an order of magnitude
>speed up over "naked slot value", and the 4.1 release even obeys all
>the MOP'ish concerns.  This context is usually (1) within the lexical
>scope of a defmethod, (2) object is lexically recognizable as one of
>the specialized parameters, and (3) slot name is compile-time constant.
>[PCL used to have this sort of context-dependent optimization also,
>but without the automated invalidation for MOP'ish concerns.]  

PCL still has this kind of context-dependent optimization.  The new
versions of PCL work the same as the old ones did, only with less
runtime optimization overhead than before (and with MOP-required
automated optimization invalidation as necessary).

And fortunately for programmers using any version of CLOS, this
open-codeable (and very fast) within-defmethod slot-value context
is probably the most common usage, dramatically reducing any potential
slot-access performance penalties CLOS implementations might face in
comparison to implementations using structures.

>Your numbers somehow don't seem to be consistent for this case --
>I get 173,913 on a Sparc2, where you get 35,000 on a Sparc1.  The
>two hardware platforms aren't _that_ much different, are they?

Mea culpa.  I had unequal compiler optimizations.  With the highest
compiler optimization settings, I get 89,000 on a Sparc1.  Thanks
for pointing out the error, and the reminder of the many pitfalls
of benchmarking.

- Trent Lange
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.lang.clos
Subject: Re: At the boundary of the MOP?
Date: 4 Sep 92 08:07:53 GMT
Organization: ILOG S.A., Gentilly, France
In-reply-to: Thomas_E_Morgan@cup.portal.com's message of 1 Sep 92 22:04:29 GMT


In article <65076@cup.portal.com> Thomas_E_Morgan@cup.portal.com writes:

   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. 

   I'm quite sure that I can get this to go (things like this 
   worked, allowing for names, in the May 90 PCL), but I am 
   curious to hear what the opionions of skillful MOP'ers are.

   Am I beyond the pale here?  This question has also made me 
   curious about exactly where the limits of the MOP design are, 
   and how those limits might be described.  (Something better
   than: "Whatever you can do, by changing the behaviors of
   the GF's in the AMOP book"

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.

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Newsgroups: comp.lang.clos
Subject: Re: Beginner's Question - CLOS
Date: 25 Aug 92 16:48:58 GMT
Article-I.D.: subnode.10552.9208251648
Organization: The Ohio State University Department of Computer and Information Science

RPG writes:

> I think this concern over dispatch time is insane. It might have made
> sense 20 years ago (that is, when C was invented) when computers were
> < .1 mips and cost more than 5 years of a hacker's salary, but not
> today when computers are > 20 mips and cost 1/5 of a hacker's salary.

I partially agree with this.  I think it would be a mistake to
add a bunch of kludgy mechanisms to the language just to speed
up dispatch time, for instance.

On the other hand, I don't think the implementors who have put
a great deal of effort into speeding up method dispatch have been
wasting their time, and I don't think it doesn't matter how much
slower CLOS is than C++ or how much slower generic functions are
than ordinary ones.

If the difference is only 10-20%, then it's not a problem; but
if we're talking small integer factors, that's a different story.
We have some programs here that take, say, 8 hours to process a
"realistic" example.  It would make a big difference to cut it
to 4.  Sure, we could wait for the next "mini-generation" of
machines (which, if recent trends continue, will be about twice
as fast) and cut it to 4 hours that way.  But if we can do that,
it would be even better to have a faster program and a faster
machine and run it in 2 hours.

It also turns out that when we use CLOS we might have to justify
this choice to customers.  It will be a lot easier to do this if
the time cost isn't very great.

Of course, method dispatch might acount for only a small faction of
the total time.  But, in other cases, it's more.  In order to tell
when it's "safe" to use generics, we need to know what cost is
involved.
Newsgroups: comp.lang.clos
From: markw@asdi (Mark Watson x6816)
Subject: PCL for AKCL (DOS version)
Organization: SAIC
X-Newsreader: Tin 1.1 PL4
Date: Tue, 25 Aug 1992 18:44:00 GMT


Does anyone have PCL running on the DOS version of AKCL?
Thanks,
  Mark Watson

Newsgroups: comp.lang.clos
From: jeff@aiai.edinburgh.ac.uk (Jeff Dalton)
Subject: Re: yacc/bison Producing LISP
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 28 Aug 1992 16:27:40 GMT

I know this is a somewhat heretical suggestion, but for most
reasonable languages, it's pretty easy to write recursive-descent
parsers "by hand".  (It's also not too hard to write some macros
that do most of the work for you.)

Newsgroups: comp.lang.clos
From: pab%glen-canyon-dam@lucid.com (Peter Benson)
Subject: Beginner's Question - CLOS
Reply-To: pab%glen-canyon-dam@lucid.com
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 26 Aug 1992 16:22:27 GMT


The problem with making these decisions is that most non-programmers (and
lots of programmers too) don't look any further than speed.  Speed just
happens to be the easiest (to the naive) thing to measure, and the most
obvioous "good thing".  I think the whole software lifetime needs to be
examined.  Is this program only going to be used once?  Do you expect to
have tens of thousands of users?  Do you intend to reimplement it?  Will
you have to reimplement it when you need to add that unforseen feature?
How long will it take to design? How long will it take to implement?  Of
course you won't know the answer to most of these questions when you're
deciding whether to use lisp, C or BASIC, but you need to ask them to give
some perspective.  

Of course the most important thing is that the software exists and
that it does what was wanted.  It is hard to look beyond the initial
implementation, but maintainability and extensibility can be important.
It is a mistake to get too caught up with speed at the expense of other
factors. 

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, 25 Aug 1992 17:23:44 GMT

   Our clients often decide between Le-Lisp and C++.  One of the factors
   they consider very strongly is benchmark results.  If we tried to tell....

This is all very interesting, but the fact remains that it is insane.
For example, I could make the clearly undeniably correct statement
that the civil war in the former Yugoslavia is insane, and others
could just as rightly point out that people will continue killing each
other for stupid reasons. Yet, my assessment of their sanity remains
correct.

Our clients make this same choice. Luckily we can offer both
solutions, and we have a lot of success helping customers decide
between them, and the result depends on their needs.

When someone cares only about performance of the resulting code, you
just warn them to design good algorithms and wave goodbye.

			-rpg-

Xref: sparky comp.lang.clos:771 comp.object:3391
From: kpt@IISA.COM (Kevin P. Tyson)
Newsgroups: comp.lang.clos,comp.object
Subject: Looking for information on CLOS based distributed object systems
Date: 1 Sep 92 01:17:05 GMT
Reply-To: kpt@iisa.com
Organization: IISA
X-Mailer: uAccess - Macintosh Release: 1.5v5

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?

Thanks in advance,
Kevin P. Tyson
(kpt@iisa.com)
Newsgroups: comp.lang.clos
From: bil@cmn16.Stanford.EDU (Bill Schottstaedt)
Subject: Re: August 28 PCL
Organization: DSO, Stanford University
Date: Tue, 1 Sep 92 14:07:55 GMT

(From Rick Taube, hkt@zkm.de)

To: rharris@ptolemy2.rdrc.rpi.edu (address bounces)
Subject: August 28 PCL

I'm trying to figure out why Aug 28 PCL runs so poorly in my  
environment -- Allegro CL 3.1.20 [NeXT] -- when compared to March 2c.  
March 2c runs the whole bench-this-clos suite in about the time it  
takes for Aug28 to do the first benchmark test. While loading the  
Aug28 PCL, I noticed that some LAP related files are loaded in March  
2c but NOT in Aug28 and am hoping that this explains my problem. They  
appear to have been commented out in August 28 defsys.lisp. In  
particular, 2c loads the files:

	Loading binary of FNGEN...
	Loading binary of LAP...
	Loading binary of PLAP...
	Loading binary of CACHE...
	Loading binary of DLAP...
	Loading binary of BOOT...

but in Aug 28 the files

	Loading binary of FNGEN...
	Loading binary of CACHE...
	Loading binary of DLISP...
	Loading binary of DLISP2...
	Loading binary of BOOT...

are loaded.

Maybe there is some problem with conditionals so that my Aug 28 pcl  
is running with no optimizations?

---
Rick Taube
hkt@zkm.de


Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Slot access performance (was Re: Beginner's Question - CLOS)
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 26 Aug 1992 05:07:48 GMT

re: This is not to pick on Lucid's native CLOS at all;  indeed, from other
    benchmarks, many of the commercial vendor's CLOS's seem to have a similar 

First, Lucid's 4.1 release shows a "naked slot value" time about a
factor of two faster than the 4.0.2 time; so that would tend to defuse
these statistics a bit.

But much more importantly is to look at SLOT-VALUE in an open-codable
context; Lucid's implementations  show almost an order of magnitude
speed up over "naked slot value", and the 4.1 release even obeys all
the MOP'ish concerns.  This context is usually (1) within the lexical
scope of a defmethod, (2) object is lexically recognizable as one of
the specialized parameters, and (3) slot name is compile-time constant.
[PCL used to have this sort of context-dependent optimization also,
but without the automated invalidation for MOP'ish concerns.]  

Your numbers somehow don't seem to be consistent for this case --
I get 173,913 on a Sparc2, where you get 35,000 on a Sparc1.  The
two hardware platforms aren't _that_ much different, are they?  Secondly,
this benchmark is mostly measuring the slot-optimization context setup
time and not the slot-access time.  The benchmark should be re-written
to do, say, 10 slot-accesses in each WITH-SLOT's or DEFMETHOD form.




-- JonL --
Newsgroups: comp.lang.clos
From: bobrow@parc.xerox.COM (Danny Bobrow)
Subject: Re: At the boundary of the MOP?
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 4 Sep 1992 16:05:31 GMT

In a paper CLOS, The shape of the Design Space, by  Dick Gabriel, JonL
White, and me, we sketch out a mechanism for using types (defined by
signatures)  as a mechanism for selecting the appropriate method of a
generic function. The paper will appear in  a book on CLOS edited by
Andreas Paepcke from MIT Press, available early next year.
Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Re: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 25 Aug 1992 19:16:59 GMT

re: Forgive me for not being fair to the vendors by not performing the
    benchmarks on a single machine, but I don't have the resources.

For curiousity sake, could  you make public your benchmark sources?

[David Moon used to have an extensive set of micro-benchmarks like
this for CLOS---back around March 1990---but I don't think Symbolics
wanted him to send them out publicly.]


-- JonL --
Newsgroups: comp.lang.clos
From: rharris@unix.ecs.rpi.edu (Richard Harris)
Subject: Re: shared :initarg problem in August 4 PCL
Organization: Rensselaer Design Research Center, RPI, Troy, NY
Date: Thu, 27 Aug 1992 19:43:23 GMT


> In August PCL (8/4/92), using a shared :INITARG to initialize two slots at
> once breaks in INITIALIZE-INSTANCE-SIMPLE with the error:
>                 Error: bad index to nthcdr: -1

In the function make-initialization-form-list (fast-init.lisp),
Change the lines:
		  (add-forms `((pop-initargs ,(* 2 npop))
			       (instance-set ,pv-offset ,slot))
			     initialize-form-list))
To:
		  (add-forms `(,@(when (plusp npop)
				   `((pop-initargs ,(* 2 npop))))
			       (instance-set ,pv-offset ,slot))
			     initialize-form-list))


  Richard Harris
Newsgroups: comp.lang.clos
From: kanderso@bbn.com
Subject: Re: Beginner's Question - CLOS
Organization: The Ohio State University Department of Computer and Information Science
Date: Wed, 26 Aug 1992 05:49:37 GMT

  To: comp.lang.clos@cis.ohio-state.edu
  Date: Wed, 26 Aug 1992 09:56:27 GMT
  Organization: The Ohio State University Department of Computer and Information Science
  From: cb@maths.bath.ac.uk
  Sender: commonloops-request@cis.ohio-state.edu
  References: <17dmf7INNb4l@early-bird.think.com>
  Subject: Beginner's Question - CLOS
  
  >How much slower is that than the C++ or C version?  Timings are meaningless
  >without some basis for comparison.
  
  Well, it's sort of like comparing apples and oranges, because
  the C version basically hard codes the Petri net and has
  lots of direct array accesses (like Place[3].count). I think the
  C compiler produces good code for direct array accesses.  However, the
  C version  has no object-oriented features--mine does.
  
  Also, the lisp version that I wrote handles marking dependent firing
  rates which the C implementor admits would slow down his
  system--though I don't know by how much.  Anyways, mine running in CMU
  Common Lisp on a Sparcstation ELC executes about 400 transitions a
  second (it's slower running in Eulisp on a Stardent).  The C version running
  on a Sparcstation 2 (I don't know how much faster that is than an ELC) executes
  about 20,000 transitions a second.  Note I was running a smaller petri net
  simulation and it had marking dependent firing rates.  That's why I just
  said that the Lisp version  is way, way, slower.
  
It sounds like you don't need C++ as much as a Petri net compiler that
takes your nice object oriented specification and spits out fast code, like
a big PROG, for example.

k
Newsgroups: comp.lang.clos