From pc at p-cos.net Mon Sep 3 12:49:42 2007 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 3 Sep 2007 14:49:42 +0200 Subject: [closer-devel] ContextL Survey September 2007 Message-ID: <02E11A8A-21B8-45E0-91C4-0459F01B9597@p-cos.net> Context-dependent behavior is becoming increasingly important for a wide range of application domains. Unfortunately, mainstream programming languages do not provide mechanisms that enable software entities to adapt their behavior dynamically to the current execution context. In collaboration with various researchers, we have developed a new programming technique called "Context-oriented Programming" (COP). ContextL - http://common-lisp.net/project/closer/contextl.html - is our first fully implemented and currently most mature programming language extension for COP and is built on top of the Common Lisp Object System (CLOS). ContextL has first been made available to the public in early 2005, and has already been adopted by a number of programmers. We would now like to assess how well ContextL has been received so far. Please consider participating in our first survey about ContextL - this will help us a lot to develop ContextL and related projects further (like Closer to MOP, etc.). You can find the survey and more information about it at http:// prog.vub.ac.be/~pcostanza/COP/survey.html Thanks a lot, Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From nallen05 at gmail.com Sun Sep 9 18:49:26 2007 From: nallen05 at gmail.com (Nick Allen) Date: Sun, 9 Sep 2007 20:49:26 +0200 Subject: [closer-devel] acl 8.0 + funcallable-standard-class metaclass Message-ID: I notice in features.txt that for ACL 8.0: "FUNCALLABLE-STANDARD-OBJECT is not used as the default superclass for classes with :metaclass FUNCALLABLE-STANDARD-CLASS." which implies to me that defining classes with a metaclass closer-mop:funcallable-standard-class otherwise works, but cl-user> (lisp-implementation-version) "8.0 [Mac OS X (Intel)] (May 10, 2007 8:10)" cl-user> (require :mop) ; Fast loading from bundle clos/mop.fasl. t cl-user> (defclass fn () () (:metaclass aclmop:funcallable-standard-class)) errors: "Class # is not yet finalized." cl-user> (defclass fn (aclmop:funcallable-standard-object) () (:metaclass aclmop:funcallable-standard-class)) (defclass fn () () (:metaclass aclmop:funcallable-standard-class)) errors: "Class # is not yet finalized." (it behaves the same way with closer-mop). am I missing something, should this work? thanks for your time Nick From pc at p-cos.net Sun Sep 9 19:41:45 2007 From: pc at p-cos.net (Pascal Costanza) Date: Sun, 9 Sep 2007 21:41:45 +0200 Subject: [closer-devel] acl 8.0 + funcallable-standard-class metaclass In-Reply-To: References: Message-ID: <96E437F4-1022-460C-843D-A8A24943444C@p-cos.net> Consider calling the following code beforehand: (unless (class-finalized-p (find-class 'standard-object)) (finalize-inheritance (find-class 'standard-object))) The CLOS MOP explicitly allows for finalization errors to occur before the first instance of a class is created. As far as I know, Allegro is the only implementation that takes advantage of this, that's why one rarely comes across this problem. Pascal On 9 Sep 2007, at 20:49, Nick Allen wrote: > I notice in features.txt that for ACL 8.0: > > "FUNCALLABLE-STANDARD-OBJECT is not used as the default superclass > for classes with :metaclass FUNCALLABLE-STANDARD-CLASS." > > which implies to me that defining classes with a metaclass > closer-mop:funcallable-standard-class otherwise works, but > > cl-user> (lisp-implementation-version) > "8.0 [Mac OS X (Intel)] (May 10, 2007 8:10)" > > cl-user> (require :mop) > ; Fast loading from bundle clos/mop.fasl. > t > > cl-user> (defclass fn () > () > (:metaclass aclmop:funcallable-standard-class)) > > errors: "Class # is not yet > finalized." > > cl-user> (defclass fn (aclmop:funcallable-standard-object) > () > (:metaclass aclmop:funcallable-standard-class)) > (defclass fn () > () > (:metaclass aclmop:funcallable-standard-class)) > > errors: "Class # is > not yet finalized." > > (it behaves the same way with closer-mop). am I missing something, > should this work? > > thanks for your time > > Nick > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From nallen05 at gmail.com Sun Sep 9 20:07:47 2007 From: nallen05 at gmail.com (Nick Allen) Date: Sun, 9 Sep 2007 22:07:47 +0200 Subject: [closer-devel] acl 8.0 + funcallable-standard-class metaclass In-Reply-To: <96E437F4-1022-460C-843D-A8A24943444C@p-cos.net> References: <96E437F4-1022-460C-843D-A8A24943444C@p-cos.net> Message-ID: On 9/9/07, Pascal Costanza wrote: > Consider calling the following code beforehand: > > (unless (class-finalized-p (find-class 'standard-object)) > (finalize-inheritance (find-class 'standard-object))) > > The CLOS MOP explicitly allows for finalization errors to occur > before the first instance of a class is created. As far as I know, > Allegro is the only implementation that takes advantage of this, > that's why one rarely comes across this problem. thanks, you nailed it. I don't know why I didn't see that before! I'll include this in my code cheers Nick From pc at p-cos.net Mon Sep 10 13:28:24 2007 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 10 Sep 2007 15:28:24 +0200 Subject: [closer-devel] define-layered-method syntax In-Reply-To: References: <20070719224643.GR29990@ocean.vvo.ru> <705094EB-FCF2-4C84-B665-B719D068DE2C@p-cos.net> Message-ID: On 30 Jul 2007, at 18:26, Attila Lendvai wrote in a response to me: >> As a small workaround for the wordiness of the >> keyword, I could accept :in as an alternative for :in-layer. Would >> that help at least a little? > > i was hesitant for a moment, but it's define-LAYERED-method after all, > so what else would :in mean? There is now a new version of ContextL in the darcs repository which additionally accepts :in everywhere where it also accepts :in-layer. Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From coffeemug at gmail.com Mon Sep 10 16:51:38 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Mon, 10 Sep 2007 12:51:38 -0400 Subject: [closer-devel] GF Invocation Protocol - state of the union? Message-ID: <87abrulazp.fsf@gmail.com> Recently I ran into a problem that needs some features from gf invocation protocol. I can't seem to figure out the status of this. Does compute-discriminating-function work on OpenMCL? Some people say it's in 1.1 prerelease. Is this the case? Is it safe to rely on it working properly? If not, is there documentation of OpenMCL's protocol somewhere? Perhaps they expose other interfaces that allow similar semantics? Is make-method-lambda supported on OpenMCL, ACL and CLisp? If not, do they offer alternative interfaces? I need to inject some code into method bodies of generic functions defined with a particular metaclass. So far the only way to do it that I can think of (aside from totally redefining defmethod or using a different macro explicitly) is to specialize make-method-lambda. Are there other ways? It seems that people would want to do this pretty often, yet make-method-lambda barely has any support. And finally, is it possible/planned to bridge the gap for these features in Closer? -- Regards, Slava Akhmechet. From pc at p-cos.net Tue Sep 11 09:51:58 2007 From: pc at p-cos.net (Pascal Costanza) Date: Tue, 11 Sep 2007 11:51:58 +0200 Subject: [closer-devel] GF Invocation Protocol - state of the union? In-Reply-To: <87abrulazp.fsf@gmail.com> References: <87abrulazp.fsf@gmail.com> Message-ID: On 10 Sep 2007, at 18:51, Slava Akhmechet wrote: > Recently I ran into a problem that needs some features from gf > invocation protocol. I can't seem to figure out the status of this. The state is in general pretty sad. > Does compute-discriminating-function work on OpenMCL? No, not in the "official" versions. > Some people say it's in 1.1 prerelease. Is this the case? Is it > safe to rely on it > working properly? I'd be surprised. So far, the documentation always said that the gf invocation protocol on MCL and OpenMCL works very differently from what is specified in AMOP, and this always sounded to me like a major undertaking to change this. But that's just my speculation. > If not, is there documentation of OpenMCL's protocol > somewhere? Perhaps they expose other interfaces that allow similar > semantics? You would have to ask on the OpenMCL mailing list. > Is make-method-lambda supported on OpenMCL, ACL and CLisp? If not, do > they offer alternative interfaces? No, it's not supported in these implementations, and there are no alternative interfaces for that. Actually, only SBCL and LispWorks support make-method-lambda (LispWorks with a slightly different API, but it's usable). > I need to inject some code into > method bodies of generic functions defined with a particular > metaclass. So far the only way to do it that I can think of (aside > from totally redefining defmethod or using a different macro > explicitly) is to specialize make-method-lambda. Are there other ways? Make-method-lambda is a function that is invoked at macroexpansion time to generate the body of a method function. It has to be called at macroexpansion time because the body has to be inserted in the correct lexical scope - since Common Lisp doesn't support first-class lexical environments, there is no other point in time at which to do this correctly. Since that's the case, there is no real loss to do the same thing with your own version of a defmethod macro. I have struggled with make-method-lambda, etc., for AspectL and ContextL for some time, until I decided to define my own define-layered-method macro - and this works very well, much better than I initially expected. Based on that experience, I think by now that the cases in which make-method- lambda is essential are rare. (It would still be a good idea if it were more widely supported, but I guess the main reason why it's not is that it complicates the optimization model for generic functions a lot.) It's a little bit easier to understand why your own method definition macros should typically be sufficient if you realize that there is actually a serious omission in CLOS itself: You can define a default method class to use in defgeneric, but there is no way to use a different method class in defmethod (which would actually be useful). However, let's assume that such a way would exist, then it's clear that the following two ways to define a specific kind of method don't really differ that much: (defmethod foo (x y z) (declare (method-class layered-method)) ...) (define-layered-method foo (x y z) ...) Both declare the use of a specific kind of method lexically, and both versions are mainly processed at macroexpansion time. (Things become more interesting if you actually also modify the parameter list for method functions by using complementary method classes and method combinations, but that would only work in SBCL and nowhere else, to the best of my knowledge - and that would indeed be something that's hard to achieve with just macros.) As a general rule of thumb: If what you want to do can be achieved by macros, it's in general probably better to indeed use macros. The CLOS MOP is interesting for cases where there are significant changes of runtime behavior which depend on dynamic properties of a program. That happens, for example, when you want your own kinds of classes, generic functions, etc., work well in conjunction with CLOS's redefinition features, among other things. But that's not the case for processing method bodies, because for CLOS, a method body is always "static" after a method metaobject has been created. > And finally, is it possible/planned to bridge the gap for these > features in Closer? I have made an attempt to do this for the generic function invocation protocol, but this amounts to essentially reimplementing almost all of it, including the processing of method combinations, which is very hairy, especially when you want good performance. So no, this won't happen because that's unreasonable. The only chance you have is to bug the vendors to provide better support for the CLOS MOP in that area. Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From coffeemug at gmail.com Tue Sep 11 16:12:47 2007 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Tue, 11 Sep 2007 12:12:47 -0400 Subject: [closer-devel] GF Invocation Protocol - state of the union? In-Reply-To: References: <87abrulazp.fsf@gmail.com> Message-ID: On 9/11/07, Pascal Costanza wrote: > The state is in general pretty sad. Thanks for the information! From pc at p-cos.net Wed Sep 12 08:39:08 2007 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 12 Sep 2007 10:39:08 +0200 Subject: [closer-devel] Re: [Openmcl-devel] GF invocation protocol In-Reply-To: References: <873axlxhx4.fsf@gmail.com> <20070911110546.H20304@clozure.com> <87hcm1dni9.fsf@gmail.com> Message-ID: <1EFDE36F-8932-4C48-A071-CBF2D6DA7C50@p-cos.net> On 12 Sep 2007, at 07:22, Vyacheslav Akhmechet wrote: > This works very nicely. My only concern is the following quote from > features.txt of the CloserMop project regarding OpenMCL: "Likewise, > the second parameter to set-funcallable-instance-function cannot be a > closure, but only a "pure" function/thunk"[1]. The code above seems to > work very well for me. Is this quote from Closer project outdated or > this is still something to worry about? > > [1] http://common-lisp.net/project/closer/repos/closer-mop/ > features.txt That's a copy&paste bug in features.txt - sorry for that. features.txt shouldn't say anything about generic functions in MCL and OpenMCL. I will fix that, thanks for spotting this! Pascal -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium From coffeemug at gmail.com Fri Sep 14 03:02:57 2007 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Thu, 13 Sep 2007 23:02:57 -0400 Subject: [closer-devel] ACL 8.0 generic-function-argument-precedence-order Message-ID: Hi, >From what I understand from MOP recommendation generic-function-argument-precedence-order is meant to return only required arguments. Quoting the recommendation, "This value is a list of symbols, a permutation of the required parameters in the lambda list of the generic function." So far I've verified that this is honored in SBCL and LispWorks, but not ACL: (defmethod foo (a b c &rest d) nil) (generic-function-lambda-list #'foo) => (A B C &REST D) Am I misunderstanding the spec? Are there plans to fix this? [1] http://www.podval.org/~sds/clisp/impnotes/mop-gf.html#gf-argument-precedence-order From pc at p-cos.net Fri Sep 14 05:32:13 2007 From: pc at p-cos.net (Pascal Costanza) Date: Fri, 14 Sep 2007 07:32:13 +0200 Subject: [closer-devel] ACL 8.0 generic-function-argument-precedence-order In-Reply-To: References: Message-ID: On 14 Sep 2007, at 05:02, Vyacheslav Akhmechet wrote: > Hi, > >> From what I understand from MOP recommendation > generic-function-argument-precedence-order is meant to return only > required arguments. Quoting the recommendation, "This value is a list > of symbols, a permutation of the required parameters in the lambda > list of the generic function." So far I've verified that this is > honored in SBCL and LispWorks, but not ACL: > > (defmethod foo (a b c &rest d) nil) > (generic-function-lambda-list #'foo) > => (A B C &REST D) > > Am I misunderstanding the spec? Are there plans to fix this? I haven't been aware of this incompatibility yet. It should be straightforward to provide a workaround in Closer to MOP, so I will look into this. Pascal > [1] http://www.podval.org/~sds/clisp/impnotes/mop-gf.html#gf- > argument-precedence-order > _______________________________________________ > closer-devel mailing list > closer-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/closer-devel -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium