From: Marco Antoniotti
Subject: WITH-ADDED-METHODS disappeared from ANSI
Date: 
Message-ID: <scf20045wuj.fsf@ferrari.PATH.Berkeley.EDU>
Hi

the Hyperspec does not mention WITH-ADDED-METHODS.  I am curious to
know what was the rationale for its demise.

Also, is it now possible to define "anonymous" methods in ANSI CL and
add them to the appropriate generic functions without too much
mangling around?

Cheers

-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472

From: Kent M Pitman
Subject: Re: WITH-ADDED-METHODS disappeared from ANSI
Date: 
Message-ID: <sfw3ekk9rpm.fsf@world.std.com>
[comp.lang.clos removed.  As a matter of principle, I abhor cross-posting
 and I won't contribute to its proliferation by engaging in material discussion
 on cross-posted discussions.]

Marco Antoniotti <·······@ferrari.path.berkeley.edu> writes:

> the Hyperspec does not mention WITH-ADDED-METHODS.  I am curious to
> know what was the rationale for its demise.

Heh.  Actually, it does mention it.  See X3J13 issue WITH-ADDED-METHODS.
(Aren't symbolically-named issues wonderful? :-)

> Also, is it now possible to define "anonymous" methods in ANSI CL and
> add them to the appropriate generic functions without too much
> mangling around?

The phrase "without too much mangling around" has no precise meaning so
this is difficult to say.  I'll go out on a limb and say "no".
You probably need the MOP (Meta-Object Protocol), which is not a part 
of ANSI CL.
From: Marco Antoniotti
Subject: Re: WITH-ADDED-METHODS disappeared from ANSI
Date: 
Message-ID: <scfg1ojwi9h.fsf@ferrari.PATH.Berkeley.EDU>
Kent M Pitman <······@world.std.com> writes:

> 
> [comp.lang.clos removed.  As a matter of principle, I abhor cross-posting
>  and I won't contribute to its proliferation by engaging in material discussion
>  on cross-posted discussions.]
> 
> Marco Antoniotti <·······@ferrari.path.berkeley.edu> writes:
> 
> > the Hyperspec does not mention WITH-ADDED-METHODS.  I am curious to
> > know what was the rationale for its demise.
> 
> Heh.  Actually, it does mention it.  See X3J13 issue WITH-ADDED-METHODS.
> (Aren't symbolically-named issues wonderful? :-)

Yep.  I found it.  Not very informative though.

> 
> > Also, is it now possible to define "anonymous" methods in ANSI CL and
> > add them to the appropriate generic functions without too much
> > mangling around?
> 
> The phrase "without too much mangling around" has no precise meaning so
> this is difficult to say.  I'll go out on a limb and say "no".
> You probably need the MOP (Meta-Object Protocol), which is not a part 
> of ANSI CL.

However the following code works as expected (I have not checked the
status of compiled code though) in both CMUCL and in ACLPC (which,
btw, implements WITH-ADDED-METHOD as per definition in CLtL2)

------------------------------------------------------------------------------

(defclass zut ()
  ((xx :accessor xx :initarg :xx))
  (:default-initargs :xx 33))

(defmethod qwe ((z zut))
  (print (xx z)))

(defun add-qwe (zz)
  (defmethod qwe :after ((z (eql zz)))
    (format t "~&Funge~%"))
  zz)

(defparameter the-z (make-instance 'zut))
(defparameter the-other-z (make-instance 'zut))

(eval-when (:load-toplevel :execute)
  (add-qwe the-z))


------------------------------------------------------------------------------

The following trace shows that the behavior is the one expected.

------------------------------------------------------------------------------

Starting lisp ...
; Loading #p"/home/porsche2/varaiya/marcoxa/.cmucl-init.lisp".
;; Loading #p"/home/porsche2/varaiya/marcoxa/lang/cl/lisp-utilities/defsystem/defsys30/defsystem.lisp".
CMU Common Lisp 18a, running on ferrari.PATH.Berkeley.EDU
Send bug reports and questions to your local CMU CL maintainer, 
<·······@path.berkeley.edu>, or to<··········@cs.cmu.edu>.
Loaded subsystems:
    Python 1.0, target SPARCstation/Solaris 2
    CLOS based on PCL version:  September 16 92 PCL (f)
    CLX X Library MIT R5.02
    Motif toolkit and graphical debugger 1.0
* 
* (compile-file "inner-defmethod.lisp")
Python version 1.0, VM version SPARCstation/Solaris 2 on 26 NOV 97 11:39:52 am.
Compiling: /home/porsche2/varaiya/marcoxa/lang/cl/inner-defmethod.lisp 26 NOV 97 11:39:35 am


inner-defmethod.sparcf written.
Compilation finished in 0:00:01.

#p"/home/porsche2/varaiya/marcoxa/lang/cl/inner-defmethod.sparcf"
NIL
NIL
* (load "inner-defmethod")
; Loading #p"/home/porsche2/varaiya/marcoxa/lang/cl/inner-defmethod.sparcf".
T
* the-z
#<ZUT {F1C5A95}>
* the-other-z
#<ZUT {F1C5EA5}>
* (qwe the-z)
33 
Funge
33
* (qwe the-other-z)
33 
33
* 

------------------------------------------------------------------------------

ACLPC behaves in the same way.

Now,  I am more than satisfied with this behavior, but (and here I
confess my laziness) I vaguely remember some restrictions on the
'compile-time' effects of 'defining macros'.  But upon inspection of
the  Sacred Hyperspec I notice that DEFMETHOD is not a "compile-time
affecting" macro.

I am just curious to know (and too lazy to deeply delve in such
matters) what are the counterindications (especially w.r.t. compiled
code and ANSI conformance) about using such idiom to define 'eql'
methods on the fly.

I'll appreciate any explanation.

Cheers

-- 
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472