Subject: Plans for clisp, and pcl vs clisp clos

From: Raymond Toy <[email-masked]>
Date: Mon, 24 Jul 1995 15:57:26 -0400

Not that Bruno as moved on to bigger and better things (thank you very
much to Bruno et. al. for clisp!), I'm curious about the future plans
for clisp.  Is it considered "feature complete" now or will more
things be done for clisp?

Also, I have a question about clisp's builtin clos system versus pcl.
What is the real difference between them?  Which one is closer to
CLTL2?  Which would you prefer?

Sorry for all the questions---I just want to be enlightened.

Ray

---

From: Marcus Daniels <[email-masked]>
Date: Mon, 24 Jul 1995 21:45:33 GMT

>>>>> "Raymond" == Raymond Toy <[email-masked]> writes:

Raymond> Not that Bruno as moved on to bigger and better things (thank
Raymond> you very much to Bruno et. al. for clisp!), I'm curious about
Raymond> the future plans for clisp.  Is it considered "feature
Raymond> complete" now or will more things be done for clisp?

I have a code generation idea that may or may not turn
out to be generally useful.  The initial application will be for
genetic programming.. sort of a threading post-compiler.  There
is a package (still in development by Dawson Engler) called VCODE to generate
native code from virtual byte codes.  

I'm working on a GNU BFD based dynamic linker in my free time. I'd
like to have portable dynamic linking support for CLISP.

Raymond> Also, I have a question about clisp's builtin clos system
Raymond> versus pcl.  What is the real difference between them?  Which
Raymond> one is closer to CLTL2?  Which would you prefer?

The builtin CLOS system lacks some of the meta object protocol
features.  PCL is complete, but big.  See chapter 28 of the impnotes
for the lowdown vs. CLtL2.

Someday, I'd like to be able to load Objective C classes and use ObjC
methods like any other generic function.  And it seems to me the ideal
way to do this is with MOP.  So yes, it is conceivable that there
might be motivation (for me) to make some extensions to the builtin
CLOS.

---

From: [email-masked] (Tomohiro Shibata)
Date: Tue, 25 Jul 95 12:19:16 JST

Hi,

   >>for the lowdown vs. CLtL2.

  I use PCL + Clisp, but it's big and heavy.

  I want to use builtin CLOS but I have one problem.

(defclass window ()
  (( x :initarg :x :accessor x )
   ( y :initarg :y :accessor y )
  )

After define above class, below redefinition causes error.

(defmethod x ((win window) &optional newx)
  (if newx
      (locate win newx (slot-value win 'y))
    (query win))
  (slot-value win 'x))

The error is :
*** - #<STANDARD-METHOD (#<STANDARD-CLASS WINDOW>)> has 1, but #<GENERIC-FUNCTION X> has 0 optional parameters

I guess this is due to lack of some MOP features of builtin CLOS.
I'd be happy if above error could be fixed.

sincerely,

p.s.
  Is there anyone who uses CLOS which consists of 1995-06-23-Clisp +
PCL ?
---------------------------------------------------------------------------
Tomohiro Shibata 	          |email  [email-masked]
Inoue-Inaba Laboratory,           |www    http://www.jsk.t.u-tokyo.ac.jp/~tom/
Department of Mechano-informatics,|
University of Tokyo; Japan        |fax	  +81-3-3815-8356

---

From: [email-masked] (Joerg-Cyril Hoehle)
Date: Tue, 25 Jul 95 11:36:00 +0200

> *** - #<STANDARD-METHOD (#<STANDARD-CLASS WINDOW>)> has 1, but #<GENERIC-FUNCTION X> has 0 optional parameters

Why do you define an accessor X for the slot X of WINDOW as you're
going to redefine at least the read method immediately after?

Maybe you should use a DEFGENERIC before any method X is generated.

 	Joerg Hoehle.
[email-masked]

---

From: [email-masked] (Tomohiro Shibata)
Date: Tue, 25 Jul 95 19:20:30 JST

Hi,
   >>going to redefine at least the read method immediately after?

  Thanks to all who informed me. It's my mistake to declare accessor
in the defclass declaration. However it can be accepted by PCL.

  This correction pleased me that builtin CLOS works fine to my program!
The features I found are :
	a. It loads CLOS programs much faster than PCL.
	b. It can't redefine the class.
	c. It doesn't allow to redefine the generic function which has
	   different parameters from the original.

sincerely,

p.s.
  I hope Clisp will includes multi-threading facility.

---

From: [email-masked] (Bruno Haible)
Date: Tue, 25 Jul 95 14:13:55 +0200

> 	   different parameters from the original.

In clisp, you can redefine a generic function with different parameters
if you first FMAKUNBOUND it. Maybe clisp should be changed to do this
(by default) and emit a warning, instead of signalling an error.

Bruno Haible                        email: <[email-masked]>
Software Engineer                   phone: +33-1-49083585