To improve the usability of the CLOS MOP across different Common Lisps ()

Vyacheslav Akhmechet | 22 Aug 2007 08:55

Re: C2MOP and class-prototype

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 <coffeemug <at> gmail.com> wrote:
> On 8/22/07, Pascal Costanza <pc <at> p-cos.net> 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.

(Continue reading)

headers

Pascal Costanza | 25 Aug 2007 00:58

Re: C2MOP and class-prototype

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

(Continue reading)

headers

Gary King | 25 Aug 2007 04:56

Re: C2MOP and class-prototype

> 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

headers

Slava Akhmechet | 25 Aug 2007 08:10

Re: C2MOP and class-prototype


> 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

(Continue reading)