Hi folks:
I'm a *very* green lisp newbie. I just read an article in Software Development
Magazine about Gregor Kiczales and his current work on aspects. The article can
be found here:
http://www.sdmagazine.com/documents/s=7134/sdm0205a/0205a.htm
He made at least one interesting statement about LISP and the meta-object
protocol.
I have a 2 part question regarding this article:
1) can LISP benefit from aspects ? I mean, does it even fit in with the LISP way
of doing things ... or does lisp have a solution to the problem already ... or
is this a non-issue ?
2) if the answer to (1) is yes (that LISP can benefit from aspects), can LISP
replicate these semantics [of aspects] ?
Thanks very much
-Alex
to email: change r191 --> att
From: Thomas F. Burdick
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <xcvadryz5vo.fsf@famine.OCF.Berkeley.EDU>
Alex <··········@R191.net> writes:
> Hi folks:
>
> I'm a *very* green lisp newbie. I just read an article in Software Development
> Magazine about Gregor Kiczales and his current work on aspects. The article can
> be found here:
>
> http://www.sdmagazine.com/documents/s=7134/sdm0205a/0205a.htm
I'm kind of doubtful that there's anything here. Maybe there is, but
I've yet to read a single article on Aspect-Oriented Programming that
had a high enough content to hype ratio for me to fiure out what
they're talking about. After a while, you start to wonder if it isn't
because there's nothing substantial to say. Kiczales' _Art of the
Meta-Object Protocol_ explained what meta-object programming was all
about so well that I was excited early in the book, and by the time I
finished it, I got what it was about. So, I know at least Kiczales is
able to explain things well ...
> He made at least one interesting statement about LISP and the meta-object
> protocol.
You mean:
We first worked on reflection and metaobject protocols. That had
almost too much power; people couldn't make effective use of it.
? I'm not sure what he means by that. Maybe that people are scared
to use the MOP because the resulting performance deterioration isn't
well understood or localized. If so, a better-designed MOP seems to
be the right answer. Or maybe he meant that it doesn't give you
enough of a pre-built framework -- kind of like if you gave someone
continuations + dynamic binding + unwind-protect and said "here you
go, what do you need a condition system for, you've got everything you
need to build one right here"? There might be some truth in that, but
what about the baby that's in the bathwater? Alas, I cannot read his mind :)
> I have a 2 part question regarding this article:
>
> 1) can LISP benefit from aspects ? I mean, does it even fit in with the LISP way
> of doing things ... or does lisp have a solution to the problem already ... or
> is this a non-issue ?
I have no idea
> 2) if the answer to (1) is yes (that LISP can benefit from aspects), can LISP
> replicate these semantics [of aspects] ?
I've been lead to believe so
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Alex" <··········@R191.net> wrote in message
········································@R191.net...
> Hi folks:
>
> I'm a *very* green lisp newbie. I just read an article in Software
Development
> Magazine about Gregor Kiczales and his current work on aspects. The
article can
> be found here:
>
> http://www.sdmagazine.com/documents/s=7134/sdm0205a/0205a.htm
>
> He made at least one interesting statement about LISP and the meta-object
> protocol.
>
> I have a 2 part question regarding this article:
>
> 1) can LISP benefit from aspects ? I mean, does it even fit in with the
LISP way
> of doing things ... or does lisp have a solution to the problem already
... or
> is this a non-issue ?
>
> 2) if the answer to (1) is yes (that LISP can benefit from aspects), can
LISP
> replicate these semantics [of aspects] ?
>
Gregor originally did AOP using Lisp macros and the CLOS MOP.
He has spent the last several years struggling to port all this to Java
by means of preprocessors and the like, and then struggling to give
presentations without using "the L word".
It's a huge travesty, quite honestly. A competent Lisp hacker can
implement all of AOP in a portable way in probably 2 to 3 days.
I am not making any of this up, and I'm not exaggerating how easy
it is to do this in Common Lisp.
From: Marco Antoniotti
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <y6csn5m5vb6.fsf@octagon.mrl.nyu.edu>
"Scott McKay" <···@attbi.com> writes:
> "Alex" <··········@R191.net> wrote in message
> ········································@R191.net...
> > Hi folks:
> >
> > I'm a *very* green lisp newbie. I just read an article in Software
> Development
> > Magazine about Gregor Kiczales and his current work on aspects. The
> article can
> > be found here:
> >
> > http://www.sdmagazine.com/documents/s=7134/sdm0205a/0205a.htm
> >
> > He made at least one interesting statement about LISP and the meta-object
> > protocol.
> >
> > I have a 2 part question regarding this article:
> >
> > 1) can LISP benefit from aspects ? I mean, does it even fit in with the
> LISP way
> > of doing things ... or does lisp have a solution to the problem already
> ... or
> > is this a non-issue ?
> >
> > 2) if the answer to (1) is yes (that LISP can benefit from aspects), can
> LISP
> > replicate these semantics [of aspects] ?
> >
>
> Gregor originally did AOP using Lisp macros and the CLOS MOP.
>
> He has spent the last several years struggling to port all this to Java
> by means of preprocessors and the like, and then struggling to give
> presentations without using "the L word".
>
> It's a huge travesty, quite honestly. A competent Lisp hacker can
> implement all of AOP in a portable way in probably 2 to 3 days.
>
> I am not making any of this up, and I'm not exaggerating how easy
> it is to do this in Common Lisp.
I concur. I actually got pretty close in implementing the early AOP
specification. It took me more time figuring out some of the not so
well known parts of CL. I am not sure the thing is completely
correct, but the idea is there. Here it is. Essentially you have to
come up with a nice METHOD-COMBINATOR that allows you to extend what
you already have in Common Lisp. The rest is macrology.
(define-method-combination standard-extra ()
((around-first (:around :first))
(around-last (:around :last))
(around-tagged (:around . *))
(around-normal (:around))
(before-first (:before :first))
(before-last (:before :last))
(before-tagged (:before . *))
(before-normal (:before))
(after-first (:after :first))
(after-last (:after :last))
(after-tagged (:after . *))
(after-normal (:after))
(primary () :required t)
)
(flet ((call-methods (methods)
(mapcar #'(lambda (method)
`(call-method ,method))
methods))
(sort-tagged-methods (methods)
(stable-sort methods #'subtypep :key #'method-qualifiers))
)
(let* ((before-tagged (sort-tagged-methods before-tagged))
(around-tagged (sort-tagged-methods around-tagged))
(after-tagged (sort-tagged-methods after-tagged))
(around (nconc around-first
around-tagged
around-normal
around-last))
(before (nconc before-first
before-tagged
before-normal
before-last))
(after (nconc after-last after-normal after-tagged after-first))
)
(let ((form (if (or before after (rest primary))
`(multiple-value-prog1
(progn ,@(call-methods before)
(call-method ,(first primary)
,(rest primary)))
,@(call-methods (reverse after)))
`(call-method ,(first primary)))))
(if around
`(call-method ,(first around)
(,@(rest around) (make-method ,form)))
form)))))
Of course, the amazing thing is that this is standard CL.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Dave Bakhash
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <c29n0vq379f.fsf@nerd-xing.mit.edu>
"Scott McKay" <···@attbi.com> writes:
> Gregor originally did AOP using Lisp macros and the CLOS MOP.
>
> He has spent the last several years struggling to port all this to Java
> by means of preprocessors and the like, and then struggling to give
> presentations without using "the L word".
>
> It's a huge travesty, quite honestly. A competent Lisp hacker can
> implement all of AOP in a portable way in probably 2 to 3 days.
Well, after reading this one:
http://www.sdmagazine.com/documents/s=7134/sdm0205b/0205b.htm
it was still hard for me to determine just how exactly one would do this
in CL using the MOP.
> I am not making any of this up, and I'm not exaggerating how easy
> it is to do this in Common Lisp.
I don't doubt that. One of my associates, a heavy Java user, wrote me
this in an email recently:
I saw Kiczales at JavaOne 2000. He was discussing how they used
AspectJ to debug Tomcat. It was so illuminating that I came back from
the lecture positively adamant about giving it a real test. I had
played around with AOP a little bit before going to JavaOne but it was
too experimental to convince anyone to take a serious [I think this was
pre 0.8 release] look. I was at <Company> at the time and we were
having massive integration issues. Basically trying to tie a lot of
unrelated games together into a cohesive system. Anyway, one of the
games kept getting hammered by a thread deadlock that we absolutely
could not trace using our commercial tracing tool [I think it was
OptimizeIt]. I made a case for AspectJ and they let me build a
debugger. I hacked one of AspectJ's game debugging examples into the
<Company> system and, in about two hours [start of coding to location
of bug], I had traced the problem down to java.awt.*, which meant that
it was an AWT level bug. Along the way, I added debugging on multiple
levels for all the executing code in <Company> just to show how easy it
was, all controlled by little checkboxes that dynamically influenced
the tracing. It was all ridiculously simple. The president of
<Company> was blown away because he had just spent *weeks* adding
traditional debugging code that was nowhere near so flexible.
He's not one to brag or make stuff up. So I think that what GK has done
with aspects, slowly introducing them to the Java community, might be
the right way _for that community_. In the end, it's pretty obvious
that he wants to give Java folks some of the same kinds of tools that we
use here.
dave
From: Marco Antoniotti
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <y6chelyk1m0.fsf@octagon.mrl.nyu.edu>
Dave Bakhash <·····@alum.mit.edu> writes:
> "Scott McKay" <···@attbi.com> writes:
>
> > Gregor originally did AOP using Lisp macros and the CLOS MOP.
> >
> > He has spent the last several years struggling to port all this to Java
> > by means of preprocessors and the like, and then struggling to give
> > presentations without using "the L word".
> >
> > It's a huge travesty, quite honestly. A competent Lisp hacker can
> > implement all of AOP in a portable way in probably 2 to 3 days.
>
> Well, after reading this one:
>
> http://www.sdmagazine.com/documents/s=7134/sdm0205b/0205b.htm
>
> it was still hard for me to determine just how exactly one would do this
> in CL using the MOP.
>
It depends what version of AspectJ you are looking at. I believe that
the latest versions of AspectJ are essentially a "high level
debugging/trace interface" packaged up into special "objects"
(i.e. "aspects").
I must say that the basic idea of aspects *is* appealing.
To implement it in the MOP (and accessing only the Generic Function
machinery) you just need to write a method combinator. Really: the
rest is macrology.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
>
> I must say that the basic idea of aspects *is* appealing.
>
> To implement it in the MOP (and accessing only the Generic Function
> machinery) you just need to write a method combinator. Really: the
> rest is macrology.
>
If it's that easy, I'd love to see a quick example.
Alan
From: Paolo Amoroso
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <mpXKPGlA6L0ufdrVDjvEUsKtsm3G@4ax.com>
On Fri, 26 Apr 2002 19:11:39 -0400, "Alan Baljeu" <·······@sympatico.ca>
wrote:
> If it's that easy, I'd love to see a quick example.
You may check article <···············@octagon.mrl.nyu.edu> in this thread.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Marco Antoniotti
Subject: Re: Question for the lisp community : Gregor Kiczales interview in SD Magazine
Date:
Message-ID: <y6c3cxer1up.fsf@octagon.mrl.nyu.edu>
"Alan Baljeu" <·······@sympatico.ca> writes:
> >
> > I must say that the basic idea of aspects *is* appealing.
> >
> > To implement it in the MOP (and accessing only the Generic Function
> > machinery) you just need to write a method combinator. Really: the
> > rest is macrology.
> >
> If it's that easy, I'd love to see a quick example.
Well, I may have hyped a bit :) Anyway: first you have to agree what
consitutes the library of AOP. I agree that the latest versions of
AspectJ are more complex to implement, but they are also at a much
lower level than the one I toyed with. AFAIK, the latest version of
AspectJm the language, as opposed to the idea of AOPm deal with some
aspects of Java semantics that are not necessarily so general. Once
you get the hang of it, it turns out that the core of your system is
writable in CL very simply. The core is something along the lines of:
==============================================================================
;;; -*- Mode: Lisp -*-
(in-package "CLAP")
(defvar *standard-extra-method-combination*
(define-method-combination standard-extra ()
((around-first (:around :first))
(around-last (:around :last))
(around-tagged (:around . *))
(around-normal (:around))
(before-first (:before :first))
(before-last (:before :last))
(before-tagged (:before . *))
(before-normal (:before))
(after-first (:after :first))
(after-last (:after :last))
(after-tagged (:after . *))
(after-normal (:after))
(primary () :required t)
)
(flet ((call-methods (methods)
(mapcar #'(lambda (method)
`(call-method ,method))
methods))
(sort-tagged-methods (methods)
(stable-sort methods #'subtypep :key #'method-qualifiers))
)
(let* ((before-tagged (sort-tagged-methods before-tagged))
(around-tagged (sort-tagged-methods around-tagged))
(after-tagged (sort-tagged-methods after-tagged))
(around (nconc around-first
around-tagged
around-normal
around-last))
(before (nconc before-first
before-tagged
before-normal
before-last))
(after (nconc after-last after-normal after-tagged after-first))
)
(let ((form (if (or before after (rest primary))
`(multiple-value-prog1
(progn ,@(call-methods before)
(call-method ,(first primary)
,(rest primary)))
,@(call-methods (reverse after)))
`(call-method ,(first primary)))))
(if around
`(call-method ,(first around)
(,@(rest around) (make-method ,form)))
form))))))
;;; end of file -- standard-extra.lisp --
==============================================================================
This is all CL (as opposed to writing a special parser and precompiler
for Java, which, incidentally departes from some of the nice features
of `javac').
The rest is macrology: how you write the DEFINE-ASPECT macro and
adding some support for aspce inheritance. All stuff that has been
done in CL since 1984, and in Lisp since the 70s.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.