From coffeemug at gmail.com Wed Aug 22 05:44:52 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Wed, 22 Aug 2007 01:44:52 -0400 Subject: [closer-devel] C2MOP and class-prototype Message-ID: <87r6lwt963.fsf@gmail.com> It looks like 'class-prototype' is broken on SBCL 1.0.7 (and C2MOP 0.41) for some built-in classes: (c2mop:class-prototype (find-class 'string)) => 42 (sb-mop:class-prototype (find-class 'string)) => 42 I didn't find any specializations of this function in C2MOP. What can I do to help support it? (It seems pretty easy to specialize on offending classes for SBCL but what about tests for all other supported implementations?) -- Regards, Slava Akhmechet. From csr21 at cantab.net Wed Aug 22 06:12:44 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 22 Aug 2007 07:12:44 +0100 Subject: [closer-devel] Re: C2MOP and class-prototype References: <87r6lwt963.fsf@gmail.com> Message-ID: <871wdwjdwj.fsf@cantab.net> Slava Akhmechet writes: > It looks like 'class-prototype' is broken on SBCL 1.0.7 (and C2MOP > 0.41) for some built-in classes: > > (c2mop:class-prototype (find-class 'string)) => 42 > (sb-mop:class-prototype (find-class 'string)) => 42 > > I didn't find any specializations of this function in C2MOP. What can > I do to help support it? (It seems pretty easy to specialize on > offending classes for SBCL but what about tests for all other > supported implementations?) Well, this is tricky, I think. CLASS-PROTOTYPE must return a direct instance of the class, but some built-in classes are abstract -- there are no direct instances of STRING in SBCL, as all strings are either VECTOR-CHARACTER, VECTOR-BASE-CHAR (or VECTOR-NIL :-). I've debated making class-prototype of an abstract built-in class signal an error; that might be a better answer. Cheers, Christophe From pc at p-cos.net Wed Aug 22 06:22:23 2007 From: pc at p-cos.net (Pascal Costanza) Date: Wed, 22 Aug 2007 08:22:23 +0200 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: <87r6lwt963.fsf@gmail.com> References: <87r6lwt963.fsf@gmail.com> Message-ID: <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> On 22 Aug 2007, at 07:44, Slava Akhmechet wrote: > It looks like 'class-prototype' is broken on SBCL 1.0.7 (and C2MOP > 0.41) for some built-in classes: > > (c2mop:class-prototype (find-class 'string)) => 42 > (sb-mop:class-prototype (find-class 'string)) => 42 > > I didn't find any specializations of this function in C2MOP. What can > I do to help support it? (It seems pretty easy to specialize on > offending classes for SBCL but what about tests for all other > supported implementations?) According to the CLOS MOP specification, the behavior of class- prototype on instances of built-in-class is undefined. (The entry for class-prototype states that it signals an error if the class has not been finalized yet, but there is no method specified for finalize- inheritance that is applicable for built-in-class.) Before I can make any changes in Closer to MOP here, I would first have to check whether the other Common Lisp implementations could live with such changes as well. My gut feeling tells me that there may be problems here. Why don't you just define your own class-prototype function for your own uses? Portable programs and third-party libraries cannot rely on specified behavior here anyway... 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 Wed Aug 22 06:51:40 2007 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Wed, 22 Aug 2007 02:51:40 -0400 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> Message-ID: On 8/22/07, Pascal Costanza wrote: > Before I can make any changes in Closer to MOP here, I would first > have to check whether the other Common Lisp implementations could > live with such changes as well. My gut feeling tells me that there > may be problems here. If it helps I ran (class-prototype (find-class 'string)) on a number of implementations available to me: CLISP: "" CMUCL: "" SBCL: 42 ACL Express: Error LispWorks: Error OpenMCL: Error > Why don't you just define your own class-prototype function for your > own uses? Portable programs and third-party libraries cannot rely on > specified behavior here anyway... I can do that. I was thrown off by the fact that CLISP, CMUCL, (and partially SBCL) returned correct results. I guess AMOP can be (and is) interpreted differently when it comes to this. P.S. Apologies for the private e-mail. I really should have sent this through GNUS because GMail keeps doing this to me. Regards, Slava Akhmechet From coffeemug at gmail.com Wed Aug 22 06:55:45 2007 From: coffeemug at gmail.com (Vyacheslav Akhmechet) Date: Wed, 22 Aug 2007 02:55:45 -0400 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> Message-ID: BTW, if calling class-prototype on built-in classes is explicitly forbidden by AMOP, would it make sense to standardize the behavior accross implementations in C2MOP (by signalling an error, for example) to prevent people on non-conforming implementations from making incorrect assumptions? On 8/22/07, Vyacheslav Akhmechet wrote: > On 8/22/07, Pascal Costanza wrote: > > Before I can make any changes in Closer to MOP here, I would first > > have to check whether the other Common Lisp implementations could > > live with such changes as well. My gut feeling tells me that there > > may be problems here. > If it helps I ran (class-prototype (find-class 'string)) on a number > of implementations available to me: > CLISP: "" > CMUCL: "" > SBCL: 42 > ACL Express: Error > LispWorks: Error > OpenMCL: Error > > > Why don't you just define your own class-prototype function for your > > own uses? Portable programs and third-party libraries cannot rely on > > specified behavior here anyway... > I can do that. I was thrown off by the fact that CLISP, CMUCL, (and > partially SBCL) returned correct results. I guess AMOP can be (and is) > interpreted differently when it comes to this. > > P.S. Apologies for the private e-mail. I really should have sent this > through GNUS because GMail keeps doing this to me. > > Regards, > Slava Akhmechet > From pc at p-cos.net Fri Aug 24 22:52:02 2007 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 25 Aug 2007 00:52:02 +0200 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> Message-ID: <1B87B0DF-DCD7-427C-9762-456F426B31E8@p-cos.net> On 22 Aug 2007, at 08:51, Vyacheslav Akhmechet wrote: > On 8/22/07, Pascal Costanza wrote: >> Before I can make any changes in Closer to MOP here, I would first >> have to check whether the other Common Lisp implementations could >> live with such changes as well. My gut feeling tells me that there >> may be problems here. > If it helps I ran (class-prototype (find-class 'string)) on a number > of implementations available to me: > CLISP: "" > CMUCL: "" > SBCL: 42 > ACL Express: Error > LispWorks: Error > OpenMCL: Error > >> Why don't you just define your own class-prototype function for your >> own uses? Portable programs and third-party libraries cannot rely on >> specified behavior here anyway... > I can do that. I was thrown off by the fact that CLISP, CMUCL, (and > partially SBCL) returned correct results. I guess AMOP can be (and is) > interpreted differently when it comes to this. This doesn't have anything to do with how AMOP is interpreted - it's simply not specified. > P.S. Apologies for the private e-mail. I really should have sent this > through GNUS because GMail keeps doing this to me. No problem. 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 Fri Aug 24 22:58:25 2007 From: pc at p-cos.net (Pascal Costanza) Date: Sat, 25 Aug 2007 00:58:25 +0200 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> Message-ID: <58D48142-B92B-4B75-B5A2-E81F7EE81589@p-cos.net> On 22 Aug 2007, at 08:55, Vyacheslav Akhmechet wrote: > BTW, if calling class-prototype on built-in classes is explicitly > forbidden by AMOP, would it make sense to standardize the behavior > accross implementations in C2MOP (by signalling an error, for example) > to prevent people on non-conforming implementations from making > incorrect assumptions? I am hesitating to do such things. The goal of Closer to MOP, at least in its current version, is to get CLOS MOP implementations closer to what AMOP specifies. Since AMOP doesn't specify anything in that regard, forcing class-prototype to throw an error in those cases goes beyond that goal - and users of the various Common Lisp implementations may actually prefer to keep the default behavior of their preferred implementation. (For non-portable programs, that's always ok.) On the other hand, I agree that this is a border case, and may be a good starting point for actually introducing improvements to the CLOS MOP - which is something I have in mind for a kind of Closer to MOP 2.0 anyway, only that I don't know whether I will ever get around to it (so don't hold your breath ;). Do other people on this list have any opinions on 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 gwking at metabang.com Sat Aug 25 02:56:06 2007 From: gwking at metabang.com (Gary King) Date: Fri, 24 Aug 2007 22:56:06 -0400 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: <58D48142-B92B-4B75-B5A2-E81F7EE81589@p-cos.net> References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> <58D48142-B92B-4B75-B5A2-E81F7EE81589@p-cos.net> Message-ID: <138DE438-6DA7-4368-864D-BDE0EBB89941@metabang.com> > Do other people on this list have any opinions on this? Hi Pascal, I agree with you that C2MOP should not alter, add, or subtract from the MOP but I also agree with Vyacheslav that it would be good if something helped enforce portability by letting programmers know that they are traveling through non-standard / undefined areas that just happen to work on their platform of choice. I suspect that a well defined list of these areas could be made. It would be nice if programmers could specify (by project (perhaps in an ASDF property of their system definition)) which things are OK and which things are not. ... -- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM From coffeemug at gmail.com Sat Aug 25 06:10:00 2007 From: coffeemug at gmail.com (Slava Akhmechet) Date: Sat, 25 Aug 2007 02:10:00 -0400 Subject: [closer-devel] C2MOP and class-prototype In-Reply-To: <138DE438-6DA7-4368-864D-BDE0EBB89941@metabang.com> (Gary King's message of "Fri\, 24 Aug 2007 22\:56\:06 -0400") References: <87r6lwt963.fsf@gmail.com> <09BCED6B-7A99-44CB-868A-6C2305F56D28@p-cos.net> <58D48142-B92B-4B75-B5A2-E81F7EE81589@p-cos.net> <138DE438-6DA7-4368-864D-BDE0EBB89941@metabang.com> Message-ID: <87sl682lhj.fsf@gmail.com> > This doesn't have anything to do with how AMOP is interpreted - it's > simply not specified. Ok. I just disagree with the following reasoning: > According to the CLOS MOP specification, the behavior of > class-prototype on instances of built-in-class is undefined. (The > entry for class-prototype states that it signals an error if the > class has not been finalized yet, but there is no method specified > for finalize-inheritance that is applicable for built-in-class.) As I understand it, the purpose of signalling an error if the class has not been finalized is to avoid tricky situations where you try to create a prototype of a partially specified class - an operation that doesn't make sense. I don't think this reasoning applies to build-in-class - there is no finalize-inheritance specialization because built in classes can be considered finalized at the time application code is evaluated. What would be the purpose of enforcing this logic on built in classes? If anything, it causes unintuitive behavior and makes class-prototype less useful without a good reason to do so. It isn't very hard to return some template values for built in classes and it seems like there are no cases where doing so would cause undesireable behavior. > On the other hand, I agree that this is a border case, and may be a > good starting point for actually introducing improvements to the > CLOS MOP - which is something I have in mind for a kind of Closer to > MOP 2.0 anyway, only that I don't know whether I will ever get > around to it (so don't hold your breath ;). One option is to introduce a flag that will control C2MOP's behavior. People could configure the library to leave such cases up to discretion of their implementation or choose a more strict mechanism that would help them to avoid depending on non-portable features. > I suspect that a well defined list of these areas could be made. It > would be nice if programmers could specify (by project (perhaps in > an ASDF property of their system definition)) which things are OK > and which things are not. Perhaps this could be combined with the general configuration flag I propose above. People would say whether they want strict or relaxed behavior and would then be able to override particular cases as necessary. -- Regards, Slava Akhmechet.