Newsgroups: comp.lang.clos
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!news.mathworks.com!tank.news.pipex.net!pipex!oleane!jussieu.fr!univ-lyon1.fr!news-rocq.inria.fr!news2.EUnet.fr!news.fnet.fr!ilog!news
From: davis@ilog.fr (Harley Davis)
Subject: Re: SLOT-VALUE/WITH-SLOTS vs. standard accessors?
In-Reply-To: pch@mystech.com's message of Wed, 30 Aug 1995 10:31:12 -0400
Message-ID: <DAVIS.95Sep11132948@halles.ilog.fr>
Lines: 58
Sender: news@ilog.fr
Nntp-Posting-Host: halles
Organization: Ilog SA, Gentilly, France
References: <pch-3008951031120001@198.3.157.39>
Date: 11 Sep 1995 11:29:48 GMT


In article <pch-3008951031120001@198.3.157.39> pch@mystech.com (Pete Halverson) writes:

> The other key issue, then, is efficiency, and here I'm somewhat less
> strong in my arguments.   Is SLOT-VALUE always faster than the equivalent
> accessor?  Is it *ever* faster?  When?  I would expect that a CLOS
> implementation *should* (in principle) be able to generate a standard
> reader or writer that's faster than the equivalent SLOT-VALUE call with a
> constant slot name, but I'm vague on how this might be done and I'm
> certainly not knowledgeable on whether it *is* done.  On Genera, at least,
> a few sample timings suggested that the standard reader methods are in
> fact faster than a constant call to SLOT-VALUE, but I daren't make
> conclusions about the rest of the CL arena from this.   Can those who
> *are* familiar with the various CLOS implementations provide any info?

FWIW, when we designed the EuLisp MOP we made the reader/writer
functions primary and basically eliminated slot-value.  The MOP has
functions like make-reader-using-slot which is called at class
finalization rather than at runtime.  The result has equivalent power
to the CLOS MOP, but lets the implementor achieve high accessor
efficiency for free, even for user-defined metaclasses.

Our basic idea is that MOP costs should be paid as early as possible
to avoid runtime overhead for extensibility.  Ideally, the MOP should
be in the compiler, but as an intermediate step, the EuLisp MOP puts
as much as possible of the cost at load-time.  Gregor and co. at Xerox
PARC are working on compile-time MOPs (or were last time I checked).

You can find out more about the EuLisp (and Ilog Talk) approach in our
paper "Balancing the EuLisp Metaobject Protocol", published in "Lisp
and Symbolic Computation" in 6/93.  Here's a BibTeX reference:

@Article{bretthauer-et-al:93,
  author =       "{Bretthauer, H.} and {Kopp, J.} and {Davis, H.E.} and
                  {Playford, K.J.}",
  title =        "{Balancing the EuLisp Metaobject Protocol}",
  journal =      "Lisp and Symbolic Computation",
  year =         "1993",
  volume =       "6",
  number =       "1/2",
  pages =        "119--138",
}

Our ideas are implemented in the commercial Lisp product Ilog Talk;
you can find out more by visiting our Web site at
<URL:http://www.ilog.com/> or by writing to info@ilog.com.  I would be
surprised if Keith Playford isn't doing something similar for
Harlequin Dylan.

-- Harley Davis
-- 

-------------------++** Ilog has moved! **++----------------------------
Harley Davis                            net: davis@ilog.fr
Ilog S.A.                               tel: +33 1 49 08 35 00
9, rue de Verdun, BP 85                 fax: +33 1 49 08 35 10
94253 Gentilly Cedex, France            url: http://www.ilog.com/

