Is a 'causally connected MOP' a good idea or not?
To explain what i mean by causally connected MOP, here is an example:
CL-USER 1 > (defclass foo ()
())
#<STANDARD-CLASS FOO 20669A64>
CL-USER 2 > (find-class 'foo)
#<STANDARD-CLASS FOO 20669A64>
CL-USER 3 > (class-name (find-class 'foo))
FOO
CL-USER 4 > (setf (class-name (find-class 'foo)) 'bar)
BAR
CL-USER 5 > (find-class 'foo)
#<STANDARD-CLASS BAR 20669A64>
CL-USER 6 > (find-class 'bar)
Error: BAR is not the name of a class
So the idea is that if i modify the meta-object of a class, the change
will not be reflected in the program. I realize why changing the name
slot doesn't renames the class for an make-instance, but this is not
an implementation question, but more of a language design one.
But, besides the name property, others are causally connected. For
example if i add a new slot object in the direct slot list, it will
appear in any new instance. So the idea is would a full causally
connected MOP be a good idea or not?
Adrian DOZSA wrote:
> Is a 'causally connected MOP' a good idea or not?
>
> To explain what i mean by causally connected MOP, here is an example:
>
> CL-USER 1 > (defclass foo ()
> ())
> #<STANDARD-CLASS FOO 20669A64>
>
> CL-USER 2 > (find-class 'foo)
> #<STANDARD-CLASS FOO 20669A64>
>
> CL-USER 3 > (class-name (find-class 'foo))
> FOO
>
> CL-USER 4 > (setf (class-name (find-class 'foo)) 'bar)
> BAR
>
> CL-USER 5 > (find-class 'foo)
> #<STANDARD-CLASS BAR 20669A64>
>
> CL-USER 6 > (find-class 'bar)
>
> Error: BAR is not the name of a class
>
>
> So the idea is that if i modify the meta-object of a class, the change
> will not be reflected in the program. I realize why changing the name
> slot doesn't renames the class for an make-instance, but this is not
> an implementation question, but more of a language design one.
> But, besides the name property, others are causally connected. For
> example if i add a new slot object in the direct slot list, it will
> appear in any new instance. So the idea is would a full causally
> connected MOP be a good idea or not?
This is one of the weird corners of the CLOS MOP, and it took myself
quite some time until I understood it.
In the first place, class-name and (setf class-name) are there for
documentation and debugging purposes. They don't say anything about
under what names a class is actually available (via find-class).
One difficulty with class-name is that a class can be available under
several names. So if you say (setf (find-class 'foo) (find-class 'bar)),
'foo and 'bar will refer to the same class metaobject. However,
class-name will still return only one name (and it may not be either of
both).
So a good way to think about it is that class-name's purpose is to
ensure that printing or debugging a class metaobject displays a useful
name, not more, not less.
However, class-name is important for the integration of classes and the
type system. Only a class with a "proper name" is available as a type
with that name. What a proper name is is defined in the HyperSpec entry
for class-name: "If S is a symbol such that S = (class-name C) and C =
(find-class S), then S is the proper name of C."
So if (class-name C) = 'foo but not (find-class 'foo) = C, then (typep O
'foo) is invalid. Likewise, if (find-class 'foo) = C but not (class-name
C) = 'foo, (typep O 'foo) is also invalid.
This all is unrelated to causal connection. You speak of causal
connection if the change of a class metaobject has (immediate) effects
on all of its instances. And that is the case in CLOS.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On May 18, 4:10 pm, Pascal Costanza <····@p-cos.net> wrote:
> Adrian DOZSA wrote:
> > Is a 'causally connected MOP' a good idea or not?
>
> > To explain what i mean by causally connected MOP, here is an example:
>
> > CL-USER 1 > (defclass foo ()
> > ())
> > #<STANDARD-CLASS FOO 20669A64>
>
> > CL-USER 2 > (find-class 'foo)
> > #<STANDARD-CLASS FOO 20669A64>
>
> > CL-USER 3 > (class-name (find-class 'foo))
> > FOO
>
> > CL-USER 4 > (setf (class-name (find-class 'foo)) 'bar)
> > BAR
>
> > CL-USER 5 > (find-class 'foo)
> > #<STANDARD-CLASS BAR 20669A64>
>
> > CL-USER 6 > (find-class 'bar)
>
> > Error: BAR is not the name of a class
>
> > So the idea is that if i modify the meta-object of a class, the change
> > will not be reflected in the program. I realize why changing the name
> > slot doesn't renames the class for an make-instance, but this is not
> > an implementation question, but more of a language design one.
> > But, besides the name property, others are causally connected. For
> > example if i add a new slot object in the direct slot list, it will
> > appear in any new instance. So the idea is would a full causally
> > connected MOP be a good idea or not?
>
> This is one of the weird corners of the CLOS MOP, and it took myself
> quite some time until I understood it.
>
> In the first place, class-name and (setf class-name) are there for
> documentation and debugging purposes. They don't say anything about
> under what names a class is actually available (via find-class).
>
> One difficulty with class-name is that a class can be available under
> several names. So if you say (setf (find-class 'foo) (find-class 'bar)),
> 'foo and 'bar will refer to the same class metaobject. However,
> class-name will still return only one name (and it may not be either of
> both).
>
> So a good way to think about it is that class-name's purpose is to
> ensure that printing or debugging a class metaobject displays a useful
> name, not more, not less.
>
> However, class-name is important for the integration of classes and the
> type system. Only a class with a "proper name" is available as a type
> with that name. What a proper name is is defined in the HyperSpec entry
> for class-name: "If S is a symbol such that S = (class-name C) and C =
> (find-class S), then S is the proper name of C."
>
> So if (class-name C) = 'foo but not (find-class 'foo) = C, then (typep O
> 'foo) is invalid. Likewise, if (find-class 'foo) = C but not (class-name
> C) = 'foo, (typep O 'foo) is also invalid.
>
> This all is unrelated to causal connection. You speak of causal
> connection if the change of a class metaobject has (immediate) effects
> on all of its instances. And that is the case in CLOS.
>
> Pascal
>
> --
> My website:http://p-cos.net
> Common Lisp Document Repository:http://cdr.eurolisp.org
> Closer to MOP & ContextL:http://common-lisp.net/project/closer/
By causal i mean that if i 'play' with the meta-object then the
program (for example future make-instances, here) or existing
instances are effected by that change. I gave the name only as an
example. I know that a change of a class metaobject has (immediate)
effects on all of its instances, but this only limited to some
predefined operations, done with specific functions (for example
change-class). But CLOS is not so 'causal' if you 'play' directly with
the metaobject. I know that what i ask i a little weird, but it's only
a curiosity.
Adrian DOZSA wrote:
> On May 18, 4:10 pm, Pascal Costanza <····@p-cos.net> wrote:
>
>>Adrian DOZSA wrote:
>>
>>>Is a 'causally connected MOP' a good idea or not?
>>
>>>To explain what i mean by causally connected MOP, here is an example:
>>
>>>CL-USER 1 > (defclass foo ()
>>> ())
>>>#<STANDARD-CLASS FOO 20669A64>
>>
>>>CL-USER 2 > (find-class 'foo)
>>>#<STANDARD-CLASS FOO 20669A64>
>>
>>>CL-USER 3 > (class-name (find-class 'foo))
>>>FOO
>>
>>>CL-USER 4 > (setf (class-name (find-class 'foo)) 'bar)
>>>BAR
>>
>>>CL-USER 5 > (find-class 'foo)
>>>#<STANDARD-CLASS BAR 20669A64>
>>
>>>CL-USER 6 > (find-class 'bar)
>>
>>>Error: BAR is not the name of a class
>>
>>>So the idea is that if i modify the meta-object of a class, the change
>>>will not be reflected in the program. I realize why changing the name
>>>slot doesn't renames the class for an make-instance, but this is not
>>>an implementation question, but more of a language design one.
>>>But, besides the name property, others are causally connected. For
>>>example if i add a new slot object in the direct slot list, it will
>>>appear in any new instance. So the idea is would a full causally
>>>connected MOP be a good idea or not?
>>
>>This is one of the weird corners of the CLOS MOP, and it took myself
>>quite some time until I understood it.
>>
>>In the first place, class-name and (setf class-name) are there for
>>documentation and debugging purposes. They don't say anything about
>>under what names a class is actually available (via find-class).
>>
>>One difficulty with class-name is that a class can be available under
>>several names. So if you say (setf (find-class 'foo) (find-class 'bar)),
>>'foo and 'bar will refer to the same class metaobject. However,
>>class-name will still return only one name (and it may not be either of
>>both).
>>
>>So a good way to think about it is that class-name's purpose is to
>>ensure that printing or debugging a class metaobject displays a useful
>>name, not more, not less.
>>
>>However, class-name is important for the integration of classes and the
>>type system. Only a class with a "proper name" is available as a type
>>with that name. What a proper name is is defined in the HyperSpec entry
>>for class-name: "If S is a symbol such that S = (class-name C) and C =
>>(find-class S), then S is the proper name of C."
>>
>>So if (class-name C) = 'foo but not (find-class 'foo) = C, then (typep O
>>'foo) is invalid. Likewise, if (find-class 'foo) = C but not (class-name
>>C) = 'foo, (typep O 'foo) is also invalid.
>>
>>This all is unrelated to causal connection. You speak of causal
>>connection if the change of a class metaobject has (immediate) effects
>>on all of its instances. And that is the case in CLOS.
>>
>>Pascal
>>
>>--
>>My website:http://p-cos.net
>>Common Lisp Document Repository:http://cdr.eurolisp.org
>>Closer to MOP & ContextL:http://common-lisp.net/project/closer/
>
>
>
> By causal i mean that if i 'play' with the meta-object then the
> program (for example future make-instances, here) or existing
> instances are effected by that change. I gave the name only as an
> example. I know that a change of a class metaobject has (immediate)
> effects on all of its instances, but this only limited to some
> predefined operations, done with specific functions (for example
> change-class). But CLOS is not so 'causal' if you 'play' directly with
> the metaobject. I know that what i ask i a little weird, but it's only
> a curiosity.
>
Wow, that is two non-required requirements in a week. Me, I am looking
for a transmission that can go from forward to reverse at fifty miles an
hour without self-destructing. I don't have a need for this, I am just
looking for it.
kenny (just praying to g*d that pascal does not reply with a metagear
suggestion)
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
On May 18, 3:03 pm, Ken Tilton <···········@optonline.net> wrote:
> Wow, that is two non-required requirements in a week. Me, I am looking
> for a transmission that can go from forward to reverse at fifty miles an
> hour without self-destructing. I don't have a need for this, I am just
> looking for it.
Easily done. Not so easy is to allow any human passengers to survive
the event.
Tim Bradshaw wrote:
> On May 18, 3:03 pm, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Wow, that is two non-required requirements in a week. Me, I am looking
>>for a transmission that can go from forward to reverse at fifty miles an
>>hour without self-destructing. I don't have a need for this, I am just
>>looking for it.
>
>
>
> Easily done. Not so easy is to allow any human passengers to survive
> the event.
>
Reminds me of the guy I met who said he and his buddy agreed at
sixty-five miles an hour to find out what would happen if they applied
the parking brake. Let's just say it is a good thing that they had
agreed on it, and that the rental car company did not ask how their car
ended up upside down.
kzo
--
http://www.theoryyalgebra.com/
"Algebra is the metaphysics of arithmetic." - John Ray
"As long as algebra is taught in school,
there will be prayer in school." - Cokie Roberts
"Stand firm in your refusal to remain conscious during algebra."
- Fran Lebowitz
"I'm an algebra liar. I figure two good lies make a positive."
- Tim Allen
Adrian DOZSA wrote:
> By causal i mean that if i 'play' with the meta-object then the
> program (for example future make-instances, here) or existing
> instances are effected by that change. I gave the name only as an
> example.
A change of name will have such an effect if you use (setf find-class).
> I know that a change of a class metaobject has (immediate)
> effects on all of its instances, but this only limited to some
> predefined operations, done with specific functions (for example
> change-class).
This is always the case in a reflective architecture. You cannot control
all aspects of an implementation, but only those that are explicitly
exposed to you (and you need to understand the documentation of the
reflective API, which is admittedly not that easy in the case of the
CLOS MOP ;). There is no such thing as "full reflection", and hence
there is no such thing as "full causal connection".
> But CLOS is not so 'causal' if you 'play' directly with
> the metaobject. I know that what i ask i a little weird, but it's only
> a curiosity.
The CLOS MOP defines only two setf functions for manipulating
metaobjects directly, for class-name and generic-function-name, and
their purpose is for documentation, debugging and integration with the
type system, not for saying something about base-level code.
Everything else can be changed via reinitialize-instance and has
well-defined effects on the base level. (You can't even use (setf
slot-value) on metaobjects because the names of the predefined slots are
not specified.)
A reflective architecture is not causally connected if you can change
meta-level entities without affecting base-level entities. For example,
in a compiled CL implementation, changing a macro definition typically
only takes effect when your base code is recompiled. Hence, there is no
(guaranteed) causal connection.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/