From pc at p-cos.net Wed Nov 1 00:36:47 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 01:36:47 +0100 Subject: [closer-devel] two defun's MIA In-Reply-To: References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> Message-ID: <8B2A0DC7-25CA-4555-BD95-DFD4492BD8F4@p-cos.net> On 1 Nov 2006, at 00:58, Attila Lendvai wrote: > > (defmethod initialize-instance :around > ((class my-class) &rest initargs > &key direct-superclasses) > (declare (dynamic-extent initargs)) > (if (loop for class in direct-superclasses > thereis (subtypep class (find-class 'my-object))) > > hm, this subtypep check errors on clisp when class is a forward > referenced class. > > i could overcome it by (and (class-finalized-p ...)...) but that > doesn't feel right. (looking at the clisp backend in closer-mop i > couldn't find anything related). Hm, that shouldn't be the case, but maybe I missed it. Clisp's support for forward-referenced-class is indeed not very good. Try (subtypep (class-name class) 'my-object) instead. It may or may not work, so please let me know if it does. > > This idiom doesn't work in some CLOS implementations, but when you > use Closer to MOP, the respective problems are fixed, so you can > use this idiom in all implementations that Closer to MOP supports. > > what do you mean by "when you use Closer to MOP"? i looked around > in the sources but couldn't find anything related. it's not an > important issue, i'm fine with sbcl, but as an opensource lib it's > not nice to be tied to implementations. Sure. I was pretty sure that this is forward-reference-class is handled properly here as well, but obviously, it's not. There are a few possibilities to fix this, either maybe in Closer to MOP, or probably better by filing a bug report with clisp. I will look into this... Cheers, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.lendvai at gmail.com Wed Nov 1 10:11:57 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 1 Nov 2006 11:11:57 +0100 Subject: [closer-devel] using a custom unbound slot marker In-Reply-To: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> Message-ID: > > One trick I have used once is to just inspect the unbound value that is > used by the CLOS implementation. You can do this in a portable way, like > this: > > (defclass test () > (test-slot)) > > (defvar +unbound-slot-value+ > (let ((test (make-instance 'test))) > (standard-instance-access test > (slot-definition-location > (find 'test-slot (class-slots (find-class 'test)) > :key #'slot-definition-name))))) > > (setf (find-class 'test) nil) > > This code assumes that the value for unbound slots remains constant for > the lifetime of an image (but I can't imagine why that would not be the > case). > fyi, clisp has all kind of trouble with this. seems like even variable reads are being checked against this marker (!?). i've managed to get a little further by capturing the value into a lambda and going through a funcall, but playing with this can bring down clisp and/or slime. -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Wed Nov 1 12:53:56 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 13:53:56 +0100 Subject: [closer-devel] using a custom unbound slot marker In-Reply-To: References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> Message-ID: <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> On 1 Nov 2006, at 11:11, Attila Lendvai wrote: > One trick I have used once is to just inspect the unbound value > that is used by the CLOS implementation. You can do this in a > portable way, like this: > > (defclass test () > (test-slot)) > > (defvar +unbound-slot-value+ > (let ((test (make-instance 'test))) > (standard-instance-access test > (slot-definition-location > (find 'test-slot (class-slots (find-class 'test)) > :key #'slot-definition-name))))) > > (setf (find-class 'test) nil) > > This code assumes that the value for unbound slots remains constant > for the lifetime of an image (but I can't imagine why that would > not be the case). > > fyi, clisp has all kind of trouble with this. seems like even > variable reads are being checked against this marker (!?). i've > managed to get a little further by capturing the value into a > lambda and going through a funcall, but playing with this can bring > down clisp and/or slime. > Unfortunately, clisp is allowed to check this. The CLOS MOP spec states that the results are undefined if the restrictions on standard- instance-access are not met. One of the restrictions is that the slot must be bound for standard-instance-access to work. The HyperSpec states that "consequences are undefined" means that "conforming code must treat the consequences as unpredictable." Specifically, "an implementation is permitted to signal an error in this case." I think this is a case where the authors of the CLOS MOP specification weren't careful enough. On the one hand, they say that standard-instance-access "is intended to provide highly optimized access", but on the other hand, the wording "the results are undefined" leaves too much room for implementations. Other indications that the authors were a little bit too careless are that they haven't specified the respective setf function, and they also haven't specified accessors for slots with :allocation :class, which makes some implementors decide to add this "feature" to standard- instance-access as well. This is certainly an area that should be fixed in a future version of the CLOS MOP specification. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Wed Nov 1 13:31:18 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 14:31:18 +0100 Subject: [closer-devel] two defun's MIA In-Reply-To: References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> Message-ID: <77BD635C-98D5-4202-9B1F-3FFBB4E67321@p-cos.net> OK, I have done a few quick checks in the various CLOS implementations, and clisp, ecl, MCL and LispWorks have problems with one way or the other. Here is a dirty workaround that should work on all systems, though: (loop for class in direct-superclasses thereis (ignore-errors (subtypep class (find-class 'my-object)))) This should get your code working. I will add more detailed checks on forward-referenced-class to the MOP Feature Tests and then proceed by either submitting bug reports and/or trying to fix things in Closer to MOP. This will take a while, though. Cheers, Pascal On 1 Nov 2006, at 00:58, Attila Lendvai wrote: > > (defmethod initialize-instance :around > ((class my-class) &rest initargs > &key direct-superclasses) > (declare (dynamic-extent initargs)) > (if (loop for class in direct-superclasses > thereis (subtypep class (find-class 'my-object))) > > hm, this subtypep check errors on clisp when class is a forward > referenced class. > > i could overcome it by (and (class-finalized-p ...)...) but that > doesn't feel right. (looking at the clisp backend in closer-mop i > couldn't find anything related). > > This idiom doesn't work in some CLOS implementations, but when you > use Closer to MOP, the respective problems are fixed, so you can > use this idiom in all implementations that Closer to MOP supports. > > what do you mean by "when you use Closer to MOP"? i looked around > in the sources but couldn't find anything related. it's not an > important issue, i'm fine with sbcl, but as an opensource lib it's > not nice to be tied to implementations. > > -- > - attila > > "- The truth is that I've been too considerate, and so became > unintentionally cruel... > - I understand. > - No, you don't understand! We don't speak the same language!" > (Ingmar Bergman - Smultronst?llet) -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium -------------- next part -------------- An HTML attachment was scrubbed... URL: From gwking at metabang.com Wed Nov 1 15:14:19 2006 From: gwking at metabang.com (Gary King) Date: Wed, 1 Nov 2006 10:14:19 -0500 Subject: [closer-devel] two defun's MIA In-Reply-To: References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> Message-ID: <373AEF31-2556-4BE9-93D8-F9BEE535EC47@metabang.com> Hi Attila, On Oct 31, 2006, at 5:53 PM, Attila Lendvai wrote: > as a small return, please find a patch for closer-mop attached that > adds this information in a file called mop-tips.txt > This is a great idea. I'd also suggest adding a CLiki page... -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikodemus at random-state.net Wed Nov 1 15:06:20 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Wed, 01 Nov 2006 17:06:20 +0200 Subject: [closer-devel] Re: using a custom unbound slot marker References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> Message-ID: <87ejsn2olv.fsf@logxor.random-state.net> Pascal Costanza writes: > Unfortunately, clisp is allowed to check this. The CLOS MOP spec > states that the results are undefined if the restrictions on > standard-instance-access are not met. One of the restrictions is > that the slot must be bound for standard-instance-access to work. > The HyperSpec states that "consequences are undefined" means that > "conforming code must treat the consequences as unpredictable." > Specifically, "an implementation is permitted to signal an error in > this case." More generally, implementation are essentially allowed to crash, burn your house, and hose your data when you hit "undefined consequences". _Unspecified_ consequences are the "harmless, but eg. an error" territory. > I think this is a case where the authors of the CLOS MOP > specification weren't careful enough. On the one hand, they say that > standard-instance-access "is intended to provide highly optimized > access", but on the other hand, the wording "the results are > undefined" leaves too much room for implementations. Other > indications that the authors were a little bit too careless are that > they haven't specified the respective setf function, and they also > haven't specified accessors for slots with :allocation :class, which > makes some implementors decide to add this "feature" to > standard-instance-access as well. Other similar oopses elsewhere: * set-funcallable-instance-fun, but no funcallable-instance-fun * slot-readers &co return _names_, not function object, which really sucks if the symbol has been eg. uninterned or fmakunbound, as that leaves you without any defined means to get at the generic function. (Just in case someone is collecting these...) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From gwking at metabang.com Wed Nov 1 15:27:43 2006 From: gwking at metabang.com (Gary King) Date: Wed, 1 Nov 2006 10:27:43 -0500 Subject: [closer-devel] CLiki page for MOP standards discussion Message-ID: <895A120E-DA61-4DCA-8C72-8EB48910B331@metabang.com> Hi, I just added a page to the CLiki to make a place to put a list of ideas for MOP 2.0. It's at http://www.cliki.net/MOP-standards- discussion and currently includes the standard-instance-access issue that Attila and Pascal have just been talking about. enjoy, -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From gwking at metabang.com Wed Nov 1 15:28:29 2006 From: gwking at metabang.com (Gary King) Date: Wed, 1 Nov 2006 10:28:29 -0500 Subject: [closer-devel] Re: using a custom unbound slot marker In-Reply-To: <87ejsn2olv.fsf@logxor.random-state.net> References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> <87ejsn2olv.fsf@logxor.random-state.net> Message-ID: I'm adding these to the new CLiki page even as I type (I have four hands ). On Nov 1, 2006, at 10:06 AM, Nikodemus Siivola wrote: > * set-funcallable-instance-fun, but no funcallable-instance-fun > > * slot-readers &co return _names_, not function object, which really > sucks if the symbol has been eg. uninterned or fmakunbound, as that > leaves you without any defined means to get at the generic function. > -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From csr21 at cantab.net Wed Nov 1 15:26:43 2006 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 01 Nov 2006 15:26:43 +0000 Subject: [closer-devel] Re: using a custom unbound slot marker References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> <87ejsn2olv.fsf@logxor.random-state.net> Message-ID: Nikodemus Siivola writes: > * set-funcallable-instance-fun, but no funcallable-instance-fun Actually I think this one is at least marginally justified; specifying a funcallable-instance-function function invalidates a historically used implementation strategy for funcallable instances. (As it turns out, the historical implementation strategy is inherently not threadsafe in a natively-threaded environment, but that's not to say that that implementation strategy is universally bad.) Cheers, Christophe From pc at p-cos.net Wed Nov 1 15:46:02 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 16:46:02 +0100 Subject: [closer-devel] two defun's MIA In-Reply-To: <373AEF31-2556-4BE9-93D8-F9BEE535EC47@metabang.com> References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> <373AEF31-2556-4BE9-93D8-F9BEE535EC47@metabang.com> Message-ID: On 1 Nov 2006, at 16:14, Gary King wrote: > Hi Attila, > > On Oct 31, 2006, at 5:53 PM, Attila Lendvai wrote: > >> as a small return, please find a patch for closer-mop attached >> that adds this information in a file called mop-tips.txt >> > > This is a great idea. I don't want to make such tips part of the Closer to MOP distribution, but would prefer this to be a separate document. I'm thinking about a "design patterns"-style collection of CLOS MOP idioms. > I'd also suggest adding a CLiki page... > > -- > Gary Warren King, metabang.com > Cell: (413) 885 9127 > Fax: (206) 338-4052 > gwkkwg on Skype * garethsan on AIM > > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Wed Nov 1 15:49:36 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 16:49:36 +0100 Subject: [closer-devel] Re: using a custom unbound slot marker In-Reply-To: References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> <87ejsn2olv.fsf@logxor.random-state.net> Message-ID: On 1 Nov 2006, at 16:26, Christophe Rhodes wrote: > Nikodemus Siivola writes: > >> * set-funcallable-instance-fun, but no funcallable-instance-fun > > Actually I think this one is at least marginally justified; specifying > a funcallable-instance-function function invalidates a historically > used implementation strategy for funcallable instances. (As it turns > out, the historical implementation strategy is inherently not > threadsafe in a natively-threaded environment, but that's not to say > that that implementation strategy is universally bad.) I agree with Christophe here. You can also always call compute- discriminating-function if you need a current version of the discriminating function. In general, it's better to use the function itself rather than its instance-function. 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 attila.lendvai at gmail.com Wed Nov 1 15:50:39 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Wed, 1 Nov 2006 16:50:39 +0100 Subject: [closer-devel] two defun's MIA In-Reply-To: References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> <373AEF31-2556-4BE9-93D8-F9BEE535EC47@metabang.com> Message-ID: > as a small return, please find a patch for closer-mop attached that adds > this information in a file called mop-tips.txt > > > This is a great idea. > > > I don't want to make such tips part of the Closer to MOP distribution, but > would prefer this to be a separate document. I'm thinking about a "design > patterns"-style collection of CLOS MOP idioms. > i tough of this because locality of related information is a good thing and people plaing with the mop most probably will use closer-mop. but otherwise any location is fine for me as long as it's easy to find. a cliki page is probably the best alternative then. MOP-design-patterns linked from MOP? -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Wed Nov 1 15:57:30 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 16:57:30 +0100 Subject: [closer-devel] slot readers and writers In-Reply-To: <87ejsn2olv.fsf@logxor.random-state.net> References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> <87ejsn2olv.fsf@logxor.random-state.net> Message-ID: On 1 Nov 2006, at 16:06, Nikodemus Siivola wrote: > > * slot-readers &co return _names_, not function object, which really > sucks if the symbol has been eg. uninterned or fmakunbound, as that > leaves you without any defined means to get at the generic function. > (loop for method in (specializer-direct-methods some-class) when (subtypep method 'standard-accessor-method) collect (cons (accessor-method-slot-definition method) (method-generic-function method))) Not convenient, but possible... 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 pc at p-cos.net Wed Nov 1 16:01:36 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 17:01:36 +0100 Subject: [closer-devel] two defun's MIA In-Reply-To: References: <53E98108-F74C-4C23-B3E7-7B3F5C536AE7@p-cos.net> <373AEF31-2556-4BE9-93D8-F9BEE535EC47@metabang.com> Message-ID: <515A87FD-D687-4B09-A1B6-848D2308F9E0@p-cos.net> On 1 Nov 2006, at 16:50, Attila Lendvai wrote: > >>> as a small return, please find a patch for closer-mop attached >>> that adds this information in a file called mop-tips.txt >>> >> >> This is a great idea. > > I don't want to make such tips part of the Closer to MOP > distribution, but would prefer this to be a separate document. I'm > thinking about a "design patterns"-style collection of CLOS MOP > idioms. > > i tough of this because locality of related information is a good > thing and people plaing with the mop most probably will use closer- > mop. I feel flattered that you say this, but I don't think that's true. ;) Secondly, the long-term goal of Closer to MOP is to become unnecessary. My hope is that sooner or later, the CLOS MOP is specified and implemented well enough that you don't need a compatibility layer anymore. Pascal > but otherwise any location is fine for me as long as it's easy to > find. a cliki page is probably the best alternative then. > > MOP-design-patterns linked from MOP? > > -- > - attila > > "- The truth is that I've been too considerate, and so became > unintentionally cruel... > - I understand. > - No, you don't understand! We don't speak the same language!" > (Ingmar Bergman - Smultronst?llet) -- Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussel, Belgium -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikodemus at random-state.net Wed Nov 1 17:29:29 2006 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Wed, 01 Nov 2006 19:29:29 +0200 Subject: [closer-devel] Re: slot readers and writers In-Reply-To: (Pascal Costanza's message of "Wed, 1 Nov 2006 16:57:30 +0100") References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> <3B524EC6-EE3A-4718-B8BA-975334006765@p-cos.net> <87ejsn2olv.fsf@logxor.random-state.net> Message-ID: <874ptj2hza.fsf@logxor.random-state.net> Pascal Costanza writes: >> * slot-readers &co return _names_, not function object, which really >> sucks if the symbol has been eg. uninterned or fmakunbound, as that >> leaves you without any defined means to get at the generic function. > (loop for method in (specializer-direct-methods some-class) > when (subtypep method 'standard-accessor-method) > collect (cons (accessor-method-slot-definition method) > (method-generic-function method))) Uh. I should have known there is a way... ;-) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From pc at p-cos.net Wed Nov 1 20:25:39 2006 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 1 Nov 2006 21:25:39 +0100 Subject: [closer-devel] using a custom unbound slot marker In-Reply-To: References: <6DCD7120-F725-438A-9BE9-9D466B2D88AD@p-cos.net> Message-ID: On 30 Oct 2006, at 15:37, Gary King wrote: > Hi Pascal, > > I thinking adding such a thing is a _good_ idea (we can add it to > the new "standard") > > On Oct 30, 2006, at 7:40 AM, Pascal Costanza wrote: > >> I think it's a pity that the CLOS MOP doesn't just specify a >> constant for this. Maybe I should add this to Closer to MOP... >> > Hm, I have thought a little bit about this, and maybe it's not a good idea after all. It could be that the low-level machinery to detect unbound slots is actually part of the MMU, or some other element at the machine level. For example, in a machine that uses tagged values, unbound could be a configuration of tag bits. In that case, "the" unbound value would probably not exist as such. Something like slot-makunbound is then indeed a better abstraction for this. I am by far not an expert in hardware / cpu / mmu matters, so maybe what I am saying here is pure nonsense. On the other hand, I wouldn't be surprised if, say, Lisp Machines had some better way to deal with unbound variables than using a constant value to represent them. And I think we should leave the door open for such possible implementations... Having said that, almost all the implementations that I have checked seem to use some constant for unbound slots. The only one that seems to behave somewhat mysteriously is MCL. An alternative to defining a constant for unbound slots would be to add explicit functions for reading and writing them. In the end, we should probably have the following set of functions: standard-instance-access (setf standard-instance-access) standard-instance-boundp standard-instance-makunbound standard-class-access (setf standard-class-access) standard-class-boundp standard-class-makunbound funcallable-standard-instance-access (setf funcallable-standard-instance-access) funcallable-standard-instance-boundp funcallable-standard-instance-makunbound funcallable-standard-class-access (setf funcallable-standard-class-access) funcallable-standard-class-boundp funcallable-standard-class-makunbound The -class- versions would be there for slots with :allocation :class. (I don't know what parameters they would take, though. Probably just whatever slot-location returns, without specifying further what it is that slot-location returns for slots with :allocation :class...) Any comments? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pc at p-cos.net Mon Nov 6 21:44:02 2006 From: pc at p-cos.net (Pascal Costanza) Date: Mon, 6 Nov 2006 22:44:02 +0100 Subject: [closer-devel] News about forward referenced classes... Message-ID: Hi, I have just performed some checks on various Lisp implementations with forward referenced classes. Here are some results: - A defclass form with :metaclass forward-referenced-class fails on most implementations. Although nothing is explicitly specified here anywhere, it's safe to assume that this behavior is ok. (To fail, that is... ;) - Interestingly, most implementations also fail when make-instances- obsolete is called on an instance of forward-referenced-class. I find this surprising as I would have expected this to be just a no-op. Does anyone have an idea why this _should_ signal an error? - Allocate-instance and change-class signal errors, which is the correct behaviour AFAICT. - Typep and subtypep fail on clisp, LispWorks and MCL. _This is a bug!_ See Section 4.3.7 Integrating Types and Classes in the HyperSpec. It specifies the semantics for typep and subtypep operating on classes without restricting them to any metaclass (so they cover built-in- class and especially structure-class as well). I will report the latter to the respective vendors / implementors. 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 boldyrev+nospam at cgitftp.uiggm.nsc.ru Thu Nov 23 16:31:05 2006 From: boldyrev+nospam at cgitftp.uiggm.nsc.ru (Ivan Boldyrev) Date: Thu, 23 Nov 2006 22:31:05 +0600 Subject: [closer-devel] Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS Message-ID: I'd like to create metaclass where slot description class depends on slot's initargs. However, EFFECTIVE-SLOT-DEFINITION-CLASS takes only class argument and initargs. But initargs passed are just standard initargs like :name, :type etc. I cannot pass other initargs to the E-S-D-C. Possible solutions: 1. (Current) Special variable is bound by COMPUTE-EFFECTIVE-SLOT-DEFINITION, and E-S-D-C just returns variable's value. It seems to be somewhat kludgey. 2. Use one class for all types of slots. But this is "anti-OOP" solution. As 1 is local kludge, 2 is global one (i.e. impacts whole program). And one impossible solution: 3. Change class of resulting slot definition with CHANGE-CLASS. But this is explicitly prohibited by MOP. Are there any other possible solutions? As I cannot change initargs of effective slot, I also have to set some slots in COMPUTE-EFFECTIVE-SLOT-DEFINITION after calling CALL-NEXT-METHOD. It is so pity that COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS is not part of the MOP. As I checked, C-E-S-D-I is defined in CMUCL/SBCL, LispWorks, Allegro CL and Clisp (where it is exported symbol). Is it worth making CLOSER-MOP-EXT package where useful extensions like C-E-S-D-I are collected? P.S. Pascal, I have read your paper, but didn't quite understand it, mostly because of poor knowledge of subject and difficulty of reading English. So, no feedback yet, sorry. -- Ivan Boldyrev Many are called, few volunteer. From pc at p-cos.net Thu Nov 23 22:14:24 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 23 Nov 2006 23:14:24 +0100 Subject: [closer-devel] Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS In-Reply-To: References: Message-ID: <0347AC9B-AD8B-4C9A-9ABC-C8EB3CDE205B@p-cos.net> On 23 Nov 2006, at 17:31, Ivan Boldyrev wrote: > I'd like to create metaclass where slot description class depends on > slot's initargs. However, EFFECTIVE-SLOT-DEFINITION-CLASS takes only > class argument and initargs. But initargs passed are just standard > initargs like :name, :type etc. I cannot pass other initargs to the > E-S-D-C. > > Possible solutions: > > 1. (Current) Special variable is bound by > COMPUTE-EFFECTIVE-SLOT-DEFINITION, and E-S-D-C just returns > variable's value. It seems to be somewhat kludgey. > > 2. Use one class for all types of slots. But this is "anti-OOP" > solution. As 1 is local kludge, 2 is global one (i.e. impacts > whole program). > > And one impossible solution: > > 3. Change class of resulting slot definition with CHANGE-CLASS. But > this is explicitly prohibited by MOP. > > Are there any other possible solutions? I don't know whether there are other solutions, but you have listed all the ones that I know about. Option 1 is the one that I use in my own code, for example in the implementation of special classes in ContextL. What I actually do is that direct slot definitions are always specialized according to the class metaobject class. So for a special-class, you always get special-direct-slot-definition metaobjects. This allows me to record any initargs for slots with the direct slot metaobjects. Only when the effective slots are created, I do this based on the list of all direct slot metaobjects in compute-effective-slot-definition. I think option 2 would be ok in general, and I wouldn't mind much whether it adheres to any OOP principles or not. The more important reason to be more specific here is that calls to slot-xyz-using-class can be optimized away when the arguments are all of standard metaclasses. So I always try to use as few metaclass specialization as possible here. I have seen option 3 being used in example code, even example code shown by Kiczales et al. In my opinion, the CLOS MOP specification is overly strict here - maybe a copy&paste issue in the spec, I don't know. Anyway, that's the reason why I don't use option 3 either. > As I cannot change initargs of effective slot, I also have to set some > slots in COMPUTE-EFFECTIVE-SLOT-DEFINITION after calling > CALL-NEXT-METHOD. Exactly. > It is so pity that COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS is not > part of the MOP. As I checked, C-E-S-D-I is defined in CMUCL/SBCL, > LispWorks, Allegro CL and Clisp (where it is exported symbol). Is it > worth making CLOSER-MOP-EXT package where useful extensions like > C-E-S-D-I are collected? Are they documented anywhere? > P.S. Pascal, I have read your paper, but didn't quite understand it, > mostly because of poor knowledge of subject and difficulty of reading > English. So, no feedback yet, sorry. No problem at all. Thanks for reading it. ;) Cheers, 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 boldyrev+nospam at cgitftp.uiggm.nsc.ru Sat Nov 25 13:43:04 2006 From: boldyrev+nospam at cgitftp.uiggm.nsc.ru (Ivan Boldyrev) Date: Sat, 25 Nov 2006 19:43:04 +0600 Subject: [closer-devel] Re: Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS References: <0347AC9B-AD8B-4C9A-9ABC-C8EB3CDE205B@p-cos.net> Message-ID: <9stl34-8hh.ln1@ibhome.cgitftp.uiggm.nsc.ru> On 9668 day of my life Pascal Costanza wrote: > I think option 2 would be ok in general, and I wouldn't mind much > whether it adheres to any OOP principles or not. I do mind, because it clutters code with unnecessary details. > The more important reason to be more specific here is that calls to > slot-xyz-using-class can be optimized away when the arguments are > all of standard metaclasses. So I always try to use as few metaclass > specialization as possible here. Currently my slot-definitions keep information about their relations to other slots. Perhaps, I should move this information from slot-level to class-level and use standard slot definitions. > I have seen option 3 being used in example code, even example code > shown by Kiczales et al. In my opinion, the CLOS MOP specification is > overly strict here - maybe a copy&paste issue in the spec, I don't > know. Anyway, that's the reason why I don't use option 3 either. The other reason is that some implementations (SBCL at least) issues error message. That's where I know about this restriction from. >> As I cannot change initargs of effective slot, I also have to set some >> slots in COMPUTE-EFFECTIVE-SLOT-DEFINITION after calling >> CALL-NEXT-METHOD. > > Exactly. But this is so inconvenient! There are good-working mechanics of initargs, and I cannot use it! >> It is so pity that COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS is not >> part of the MOP. As I checked, C-E-S-D-I is defined in CMUCL/SBCL, >> LispWorks, Allegro CL and Clisp (where it is exported symbol). Is it >> worth making CLOSER-MOP-EXT package where useful extensions like >> C-E-S-D-I are collected? > > Are they documented anywhere? C-E-S-D-I is documented in Clisp Implementation Notes. Other implementations have C-E-S-D-I unexported (as part of PCL implementation). -- Ivan Boldyrev Sorry my terrible English, my native language is Lisp! From pc at p-cos.net Thu Nov 30 18:43:58 2006 From: pc at p-cos.net (Pascal Costanza) Date: Thu, 30 Nov 2006 19:43:58 +0100 Subject: [closer-devel] Re: Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS In-Reply-To: <9stl34-8hh.ln1@ibhome.cgitftp.uiggm.nsc.ru> References: <0347AC9B-AD8B-4C9A-9ABC-C8EB3CDE205B@p-cos.net> <9stl34-8hh.ln1@ibhome.cgitftp.uiggm.nsc.ru> Message-ID: On 25 Nov 2006, at 14:43, Ivan Boldyrev wrote: > On 9668 day of my life Pascal Costanza wrote: >> I think option 2 would be ok in general, and I wouldn't mind much >> whether it adheres to any OOP principles or not. > > I do mind, because it clutters code with unnecessary details. That's of course indeed a valid position to take. >> The more important reason to be more specific here is that calls to >> slot-xyz-using-class can be optimized away when the arguments are >> all of standard metaclasses. So I always try to use as few metaclass >> specialization as possible here. > > Currently my slot-definitions keep information about their relations > to other slots. Perhaps, I should move this information from > slot-level to class-level and use standard slot definitions. Maybe this is not necessary. The possible impact on efficiency that I was talking about only occurs when you define methods on slot-xyz- using-class, like this: (defmethod slot-value-using-class ((class my-class) object (slotd my- slot-definition)) ...) When a slot is a standard-slot-definition, and methods on slot-xyz- using-class don't apply, a CLOS implementation has a chance to optimize the overhead of calling slot-value-using-class away. If you don't specialize slot-xyz-using-class, this doesn't matter because there is no method that could interfere with efficiency concerns. >> I have seen option 3 being used in example code, even example code >> shown by Kiczales et al. In my opinion, the CLOS MOP specification is >> overly strict here - maybe a copy&paste issue in the spec, I don't >> know. Anyway, that's the reason why I don't use option 3 either. > > The other reason is that some implementations (SBCL at least) issues > error message. That's where I know about this restriction from. Ah, ok. >>> As I cannot change initargs of effective slot, I also have to set >>> some >>> slots in COMPUTE-EFFECTIVE-SLOT-DEFINITION after calling >>> CALL-NEXT-METHOD. >> >> Exactly. > > But this is so inconvenient! There are good-working mechanics of > initargs, and I cannot use it! > >>> It is so pity that COMPUTE-EFFECTIVE-SLOT-DEFINITION-INITARGS is not >>> part of the MOP. As I checked, C-E-S-D-I is defined in CMUCL/SBCL, >>> LispWorks, Allegro CL and Clisp (where it is exported symbol). >>> Is it >>> worth making CLOSER-MOP-EXT package where useful extensions like >>> C-E-S-D-I are collected? >> >> Are they documented anywhere? > > C-E-S-D-I is documented in Clisp Implementation Notes. Other > implementations have C-E-S-D-I unexported (as part of PCL > implementation). OK, this looks indeed like a good and convenient addition to the protocol. I will add this to my ever growing todo list for a possible revision of the CLOS MOP spec. (Don't hold your breath. Don't even think about holding your breath!) Maybe such additions are also good candidates for CDRs... 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 attila.lendvai at gmail.com Thu Nov 30 19:04:43 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 30 Nov 2006 20:04:43 +0100 Subject: [closer-devel] Re: Initargs of slot definitions: I miss COMPUTE-E-S-D-INITARGS In-Reply-To: References: <0347AC9B-AD8B-4C9A-9ABC-C8EB3CDE205B@p-cos.net> <9stl34-8hh.ln1@ibhome.cgitftp.uiggm.nsc.ru> Message-ID: > OK, this looks indeed like a good and convenient addition to the > protocol. I will add this to my ever growing todo list for a possible > revision of the CLOS MOP spec. (Don't hold your breath. Don't even > think about holding your breath!) hehe :) > Maybe such additions are also good candidates for CDRs... don't forget the stuff at cliki.net: http://www.cliki.net/MOP-standards-discussion -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet)