HDTenEightyP/NetNews huggingface dataset:
From: jonl%kuwait@lucid.com (Jon L White)
Subject: Re: Beginner's question and method lookup
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 20 Aug 1992 18:25:38 GMT

re: If there were sufficiently smart compilers, there would be no programmers.

Great quote!  I love it!

[Seriusly, though, that *is* the goal of much computer science work --
to make computer usage more available to the non-programmer (and we
*all* know that to use a computer effectively is to hack it.)  On the
other hand, you can't get blood out of a turnip . . . ]



re: Date: Wed, 19 Aug 1992 23:15:50 GMT
    From: dcmartin@fascet.msi.com (David C. Martin)
    Subject: Re: Beginner's Question - CLOS

    . . . In fact, you can determine at compile time
    what the argument types are and then put in the appropriate call to the
    appropriate function.

    Date: Thu, 20 Aug 1992 01:48:16 GMT
    From: dcmartin@fascet.msi.com (David C. Martin)
    Subject: Re: Beginner's question and method lookup
    . . . 
    You might be surprised at the work that both Franz and Lucid have done with
    their CLOS implementations.  I have talked about this issue with John
    Foderero @ Franz and he has put hooks in so that if you wish to have
    static class hierarchies you can do complete determination, i.e. static 
    binding for the executable.

David, if it were possible to do  "complete determination i.e. static 
binding for the executable"  at compile time, then there would be no 
need for "virtual" functions in C++.   Do you understand the fundamental
problem posed by having same-named methods on a class and and on a
derived (sub) class?  the dispatch from a higher method cannot determine
at compile time whether or not a sub-called method[*] is the one defined
on the same statically determinable class or one of those defined on a 
derived (sub) class.  I talked about this topic at the CLOS versus C++ 
debate last week at the 1992 Lisp Users and Vendors conference.

John Burger also alluded to this problem in his message of 
Thu, 20 Aug 1992 07:23:55 GMT, as did Barry Margolin in his msg
of 20 Aug 1992 16:06:25 GMT.  But perhaps they weren't forceful enough.


-- JonL --


[*] "sub-called method" -- I just mean that if a method on function FOO
    calls a function BAR (which is also defined by "methods"), then the
    call to BAR from within the method on FOO will lead to the execution 
    of some method on BAR, which I am calling the "sub-called method".

Xref: sparky comp.lang.clos:693 comp.object:3298
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.lang.clos,comp.object
Subject: Re: Beginner's Question - CLOS
Date: 21 Aug 92 19:42:01 GMT
Article-I.D.: andrew.AeZPS9m00awK897kVo
	<1992Aug19.213818.21709@tfs.com>
	<DCMARTIN.92Aug19151550@fascet.msi.com>
	<170fu1INNmfh@early-bird.think.com>
	<PCG.92Aug21005641@aberdb.aber.ac.uk>
Organization: Carnegie Mellon, Pittsburgh, PA

>Fully agreed, but this information can be easily deduced by a 'system
>builder', i.e. an intelligent linker, like Eiffel has (for more or less
>this reason). A system builder can create a complete list of all the
>types in an application (unless they can be defined at run time), and
>can do such overload resolution at system building time, statically. I
>think a 'system building' tool is something that is quite useful in
>general, especially if it can be used more or less incrementally.

Such a system builder is only useful in non-OO operating systems or
environments:

In such OO-environments (like Smalltalk), each class is shared among all
applications (and even used by the system itself) which means that you
can't adapt a class to a particular situation as it is dynamically used
and loaded. On the other side, this permits to diminish drastically
memory consumption (just think of the standard C libraries)

Cheers, Stefan Monnier



-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
Newsgroups: comp.lang.clos
From: kanderso@bbn.com
Subject: Re: Beginner's question and method lookup
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 21 Aug 1992 05:44:42 GMT

  From: "David C. Martin" <dcmartin@fascet.msi.com>
  Organization: Molecular Simulations, Inc.
  Email: dcmartin@msi.com or uunet!dcmartin
  Phone: 408/522-9236 (O)
  To: Jon L White <jonl%kuwait@lucid.com>
  Cc: kanderso@BBN.COM, dcmartin@msi.com, john@linus.mitre.org, eric@tfs.com, 
      barmar@think.com, comp.lang.clos@cis.ohio-state.edu
  Subject: Re: Beginner's question and method lookup 
  Date: Thu, 20 Aug 92 13:39:30 -0700
  Sender: dcmartin@msi.com
  
  Jon L White writes:
  
      David, if it were possible to do  "complete determination
      i.e. static binding for the executable"  at compile time,
      then there would be no need for "virtual" functions in
      C++.   Do you understand the fundamental problem posed by
      having same-named methods on a class and and on a derived
      (sub) class?  the dispatch from a higher method cannot
      determine at compile time whether or not a sub-called
      method[*] is the one defined on the same statically
      determinable class or one of those defined on a derived
      (sub) class.  I talked about this topic at the CLOS versus
      C++ debate last week at the 1992 Lisp Users and Vendors
      conference.
  
  Yes, I do understand that you can't do *complete* determination, but I meant
  that you didn't always need to do table lookups for cases in which you would
  not use "virtual" functions in C++.  I did not mean that you can always do
  static determination for solutions in all know problem space.  I should have
  been more specific.
  
Yes, but that leads to a rather "sticky" kind of object oriented
programming, if you consider it object oriented at all.  For example, the
function a_function takes a pointer to an instance of a high level object
class, HLObject, and invokes the member function (effective method)
a_emethod on it.

  void a_function(HLObject * x)
  {
    x->a_emethod();  // Always equivalent to x->HLObject::a_emethod().
    // ...
  }

If you pass in a pointer to a class, B, built on HLObject, a_function always
works the same way - not very object oriented.  If you decide you want the
behavior of a_function to depend on class B, you must declare a_emethod
virtual in the definition of the class HLObject.  Hopefully, you have sources.

C++ programmers are encouraged to use non virtual member functions, to
avoid the time space overhead of virtual member functions.  This doesn't
seem to encourage very object oriented programming.

k
Xref: sparky comp.lang.clos:695 comp.object:3303
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.clos,comp.object
Subject: Re: Beginner's Question - CLOS
Date: 23 Aug 92 19:58:18 GMT
	<DCMARTIN.92Aug19151550@fascet.msi.com>
	<170fu1INNmfh@early-bird.think.com>
	<PCG.92Aug21005641@aberdb.aber.ac.uk>
	<AeZPS9m00awK897kVo@andrew.cmu.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 21 Aug 92 19:42:01 GMT, sm86+@andrew.cmu.edu (Stefan Monnier) said:

pcg> A system builder can create a complete list of all the types in an
pcg> application (unless they can be defined at run time), and can do
pcg> such overload resolution at system building time, statically. I
pcg> think a 'system building' tool is something that is quite useful in
pcg> general, especially if it can be used more or less incrementally.

sm86> Such a system builder is only useful in non-OO operating systems
sm86> or environments:

Ahhhh, capability OSes tend to be a big interest of mine...

sm86> In such OO-environments (like Smalltalk), each class is shared
sm86> among all applications (and even used by the system itself)

and I think we can do better here, even if I have seen nothing like what
I am going to describe.

A lot of optimization can be done only by more or less early reduction;
for example, the system builder reduces statically the overloading info
for an entire application. You are right that in traditional OO
environments this cannot be done, but this is only because it is assumed
that the entire application can be modified after system building:

sm86> which means that you can't adapt a class to a particular situation
sm86> as it is dynamically used and loaded.

More precisely use and load don't give problems, it's modification that
might cause problems.

It might be entirely possible, combining ideas from Reid's versioning
and Bishop's ORSLA and Baker's collector and Hewitt's variation of it,
to have the system builder generate systems from 'frozen' originals or
sources, and maintain dependency links. If the originals are modified, a
new version is generated, and the system builder reruns and produces a
new version of the reduced/optimized application.

Clients active at the time the new version is created just ignore it.

I think that something like this is actually needed to support *mutable
typing* systems, in which it is possible to change data formats at run
time.

--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.lang.clos
From: jonl%kuwait@lucid.com (Jon L White)
Subject: undefmethod
Organization: The Ohio State University Department of Computer and Information Science
Date: Thu, 20 Aug 1992 00:20:22 GMT

re: last week I asked about how to remove a method. here's the solution I
    came up with in the end:
    . . .

I was out of town last week and didn't see your msg; but Lucid has always
had a function named UNDEFMETHOD, which takes a method specification as an
argument.  

Some sample calls, in the method-spec form, would be

 (undefmethod '(method some-generic-fn (standard-object stream)))

 (undefmethod '(method initialize-instance :after (green-turtle)))

Many other functions take "method specifications" as arguments.


UNDEFMETHOD is "homed" in the LUCID-COMMON-LISP package and thus
would be inherited in a normallly defaulted package; or you could 
write LCL:UNDEFMETHOD.


-- JonL --
Newsgroups: comp.lang.clos
From: A.H.Al_ashaab@lut.ac.uk (AH Al_ashaab)
Subject: is PCL/CLOS commercially supported?
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 17 Aug 1992 12:37:47 GMT

Hi
I would like to ask this question..
Is PCL/CLOS commercially supported? If YES how is supporting it?

Thanks
Ahmed AL-ASHAAB
Manuf. Eng Dept., Loughborough Univ of Tech
Loughborough, Leics LE11 3TU, England.
EMail : A.H.Al_ashaab@lut.ac.uk  OR     ahmed@mansun.lut.ac.uk
Tel 0509-263171 Ext. 4247       Fax. 0509-267725

Newsgroups: comp.lang.clos
From: wbm@freedom.stanford.edu (Wally Mann)
Subject: Re: CLOS Stylistic Questions -- Program Structuring
Organization: The Ohio State University Department of Computer and Information Science
Date: Tue, 18 Aug 1992 18:56:29 GMT

HI,
I got to put Temenos to work in a very direct way last night
facilitating a meeting to debrief a BAMRU climbing accident.
A trainee slipped 1000 feet down a glacier (tumbled, actually)
on Shasta, cracked his knee, had to be helo evac'd, and operated
on.  It was a relatively unsafe practice and a lot of folks
were upset.  It went pretty well ... we got to a lot of core
issues underlying the poor practice ... most of it revolved 
around poor interpersonal communication.

Yeah ... I have to be in Mill Valley 2 hours before you. 
If you want, I can put you in touch with other PA area folks
who are going if you just want to ride up with someone.  Or,
if you want to leave here at ... well, actually I'm going to
leave here around 2pm and drop some food off at the hotel.
Let me know if you want some names of other local folks.
I don't know of anyone you would know.

We will have some time to hang out and talk in the evenings.
(depending on how late you want to stay up.)

Oh ... I'm not sure I mentioned this before.  You probably want
to avoid my facilitation group.  It's not the end of the world
if you get in it, but it is supposed to work better if you are
in the small group with folks you don't know as well.  You get
feedback that is less colored by history.  And, just so you
don't feel slighted, each facilitator will be focused on their
respective groups.  So given that I probably won't have you in
my group, we actually won't be hanging out a lot during thw
the workshop itself.  Last time I thought this was going to
be  a drag, but it turned out that it was great to be sharing
the experiences together, and then check in at little moments
about how it was going.  I'm not sure this makes sense ... 
mostly I just wanted to be sure you knew that I'll be busy
as a son-of-a-gun the entire time.

See ya soon,
Wally
From: chyde@pecos.ads.com (Clinton Hyde)
Newsgroups: comp.lang.clos
Subject: a defclass helper
Date: 19 Aug 92 23:36:02 GMT
Distribution: comp
Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
	960-7300


here's a convenient helper which makes writing defclass forms MUCH
easier.


;;;a quickie macro which renders defclass forms from a much simpler version.

(DEFMACRO dclass (name incl slots &rest options)
  `(DEFCLASS ,name ,incl ,(MAPCAR #'(lambda (slot)
				      (if (listp slot)
					  slot
					(LIST slot 
					      :initform ()
					      :initarg (INTERN (STRING slot) :keyword)
					      :accessor slot)))
				slots)
     ,@options))


usage is:

(dclass cdp-base nil (name highlighted owner parent output-record
			explanation))

this expands to

(defclass cdp-base () 
 ((name :initform () :initarg :name :accessor name)
  ...))

__OR__

(dclass cdp-base nil (name 
			(some-slot :initform (do-something) :accessor get-some-slot)
			explanation))

which expands to

(defclass cdp-base () 
 ((name :initform () :initarg :name :accessor name)
  (some-slot :initform (do-something) :accessor get-some-slot)
  ...))

i'm using this a lot these days. I hate typing all that really obvious
extra garbage--FLAVORS managed to default things the right all the
time (auto-built accessors, etc), and I'd like CLOS to do so too.

 -- clint
--

Clint Hyde		"Give me a LispM or give me death!" -- anonymous

Advanced Decision Systems	Internet:  chyde@chesapeake.ads.com
2111 Wilson Blvd #800
Arlington, VA 22201		(703) 875-0327
Newsgroups: comp.lang.clos
From: lange@lanai.cs.ucla.edu (Trent Lange)
Subject: Re: PCL structure methods
Organization: UCLA Artificial Intelligence Laboratory
Date: Wed, 19 Aug 92 00:05:58 GMT

In article <9208182008.AA19599@dice0> rharris@rdrc.rpi.edu writes:
>
>The problem is that the class pcl::structure-object is supposed to
>be a superclass of every class having metaclass structure-class, and
>this requires a change to the way defstruct works.
>I can think of three ways to fix this problem:
>
> (1) Change defstruct to :include the structure named structure-object whenever
>     an :include option is not provided and the name is not structure-object
>     and :type is not specified.  Move the definition of structure-object
>     from pcl/defs.lisp the place that defstruct is defined.  Then change PCL
>     to import the symbol structure-object from whatever package defined it.
>
> (2) Change typep and subtypep to simulate the effect of (1).
>
> (3) Change the macro class-test (pcl/methods.lisp), to be the following:
> [...]
>
>  Richard Harris


From an implementational and maximal portability standpoint, I would
suggest both (1) and (3).

July 92 PCL already redefines defstruct so that it has access to the
information in the defstruct for its structure-classes.  (It also, of
course, calls the original lisp defstruct macro).  Adding the check
to :include structure-object if an :include is not provided would
then be simple, and would have the desired effects on typep and
subtypep, without having the efficiency or portability problems
that changing typep and subtypep (2) might entail.

I would also change the CLASS-TEST macro as you suggest (3), since
there will always be some structures defined before PCL is loaded
that will therefore not :include structure-object.

These are obviously only partial solutions (pre-PCL structures being
the problem), but it's about the best that a portable CLOS loaded on
top of specific lisp implementations can do.

I'll make these changes to July 92 PCL and update it on parcftp, unless
somebody points out a problem that Richard or I haven't seen.

- Trent Lange

Newsgroups: comp.lang.clos
From: brw@hertz.njit.edu (Brian White)
Subject: help installing PCL, please
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 21 Aug 1992 19:45:35 GMT

I am currently attempting to install PCL (version within August-4-92-PCL.tar.Z
file found on rascal.ics.utexas.edu) using akcl (version 1-165, which I believe
is the most current of AKCL). Would someone out there please give me some
information concerning the installation of PCL? I haven't used Lisp in *many*
years and the included installation "information" is rather lacking...

The target system is a DECsystem 5900 running Ultrix 4.2A. Please respond via
email; if the information I receive is explicit enough for me to figure out :^),
I'll be glad to put it up for anonymous ftp to possibly limit these questions
in the future.

Thanks for any help,

Brian White
System Manager
Computing Services Dept.
New Jersey Institute of Technology
brw@hertz.njit.edu
201-596-3380
From: Thomas_E_Morgan@cup.portal.com
Newsgroups: comp.lang.clos
Subject: PCL and MACL 2.0, anyother MOP?
Date: Wed, 12 Aug 92 19:10:08 PDT
Organization: The Portal System (TM)
Distribution: usa

I could use some advice.  I need more of the MOP than is present in the 
MACL 2.0 release, and find that the MACL 1.3.2 release doesn't run in my 
environment.

First, how badly will I regret attempting to get PCL working in MACL 2.0?  
I've made an innocent stab, making some easy changes in some LOW.LISP 
code and in some DEFSETF's, but have bumped into changes in environment 
representations that bother the walker code.  Am I wandering into a swamp 
here?

Second, if the answer is yes, then what LISP and what machine would you 
suggest I get myself to run a LISP with a strong MOP - either one that comes 
with the LISP, or PCL.  (Money is not exactly no object here, but I don't want 
to spend unreasonable amounts either.  The less I have to think about the 
machine, the better.).

   ...Tom M 
Newsgroups: comp.lang.clos
From: dcmartin@fascet.msi.com (David C. Martin)
Subject: C++ not object-oriented..
Organization: Molecular Simulations, Inc.
Date: Fri, 21 Aug 1992 00:10:47 GMT

--------
kanderso@BBN.COM writes:

   C++ programmers are encouraged to use non virtual member functions, to
   avoid the time space overhead of virtual member functions.  This doesn't
   seem to encourage very object oriented programming.

I *never* said that C++ was an object-oriented language!

dcm
Newsgroups: comp.lang.clos
From: A.H.Al_ashaab@lut.ac.uk (AH Al_ashaab)
Subject: is PCL/CLOS commercially supported?
Organization: The Ohio State University Department of Computer and Information Science
Date: Mon, 17 Aug 1992 12:44:59 GMT


sorry but in the first message I said..
"Is PCL/CLOS commercially supported? If YES how is supporting it?
I meant  "WHO" is supporting it?

Ahmed
Newsgroups: comp.lang.clos
From: welch@news.cis.ohio-state.edu (Arun Welch)
Subject: Re: Common Lisp is a dpANS in Public Review! (fwd)
Organization: The Ohio State University Department of Computer and Information Science
Date: Fri, 21 Aug 1992 18:12:53 GMT

I offered to put the CL files on our ftp server, and recieved the following in
response. Now don't all ftp it at once...

...arun



Forwarded message:
> From 75300.2354@compuserve.com Fri Aug 21 09:12:30 1992
> Date: 21 Aug 92 09:08:55 EDT
> From: Dan Arnold <75300.2354@CompuServe.COM>
> To: Arun Welch <welch@cis.ohio-state.edu>
> Subject: Re: Common Lisp is a dpANS in Public Review!
> Message-Id: <920821130855_75300.2354_CHE23-12@CompuServe.COM>
> 
> Arun,
> 
> Public access copies of the Tex sources and Unix-compressed DVI files for 
> dpANS Common Lisp are available by anonymous FTP on Internet from the host 
> Beta.Xerox.COM in the directory "/pub/cl/document/*".
> 
> We are currently investigating guidelines for accepting public review comments
> online through CompuServe e-mail facilities, but unfortunately will not be 
> able to accept them for this particular Draft Standard.  We are anticipating 
> running a beta test on one in the November-December time frame.  All comments 
> for this Draft Standard must be sent in hard copy to Lynn Barra at the address
> on the Press Release, along with a copy forwarded to ANSI BSR.
> 
> If you have any further questions please contact me at this email address.
> 
> Dan
>
From: gregor@parc.xerox.com (Gregor Kiczales)
Newsgroups: comp.lang.clos
Subject: Re: PCL and MACL 2.0, anyother MOP?
Date: 13 Aug 92 17:06:42 GMT
Article-I.D.: tracer-b.GREGOR.92Aug13100642
Distribution: usa
Organization: Xerox Palo Alto Research Center

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

   First, how badly will I regret attempting to get PCL working in MACL 2.0?  
   I've made an innocent stab, making some easy changes in some LOW.LISP 
   code and in some DEFSETF's, but have bumped into changes in environment 
   representations that bother the walker code.  Am I wandering into a swamp 
   here?

As Trent Lange says in his reply, and assuming that MACs are what you
want to be with in the long run, I would think this would be the way you
want to go.  Right now, the newest PCL is the most conforming
implementation of the MOP, and its pretty efficient to boot.  (Although
its certainly less efficient than the Apple 2.0 CLOS.)

Unless Apple has changed things dramatically, getting the new PCL
running in MCL 2.0 shouldn't take too much work.  You may even be able
to get someone at Apple to help you do it.

Gregor