Re: Container model - pictures and questions
HaloO,
Autrijus Tang wrote:
1) I would move the ::name to the Pad level. The idea is
that ::name is some less specific supertype of the
Fantastique Four ($@%) if more than one of them exists
on the container level.
Please annotate this idea with the code. You mean:
my $a = 3;
my @a = 1..10;
And somehow ::a is the supertype of the two!?
Yes. I should somewhat behave like any($a,@a) without flattening @a.
any($a,@a).does(Item) # true
any($a,@a).does(Array) # true
Another idea of mine is to think of $a beeing the short form of
Item::a and @a for Array::a. Or in yet another way the sigils
are not really part of the name but a split into four sublevels
available everywhere. This might nicely play together with other
languages on the Parrot level. For example sub foo {...} enters
the name 'foo' in the Code branch of the immediately surrounding
namespace. Within ::foo one can find information about lexical
variable types like ::foo::MY::Item::a, or ::foo::ENTER, ::foo::LEAVE,
::foo::BEGIN etc. This information is retrieved when the referential
environment of a foo invocation shall be bound. The signature might
also be a subnamespace ::foo::SIGNATURE::Item::x, etc. Positional
parameter types could e.g. be available as ::foo::SIGNATURE::1,
::foo::SIGNATURE::2, etc.
Here it would be nice to have relaxed whitespace constraints on ::,
see below. Otherwise things like ::foo::SIGNATURE::Item of Int::x might
work in PIL only. And I think inline PIL should be available to
low-level tasks. Operator ::= falls in that category as well. Not
to mention conditional lookup with ?? :)
2) I don't understand why you need two levels of indirection
firstly the container and then the cell. Not to mention
the third one to the tied thingy.
Because assignment (=), binding (:=) and tie are operating on different
levels, the same way Perl 5 typeglobs and tie works.
Yeah, but Perl5 has no explicit type system. It treats Foo::Bar
as a string that is only structured by convention. Perl6 has a
full-blown, hierarchical namespace and barewords are looked up
there. And the three operations =, := and .tie are found there
as well. They are Code subtypes and---citing the
::Matrix::Reloaded::KeyMaker---do what they are meant to do.
3) Why is the link from the container labeled with :=
but the link between the cell and the value with =?
Because you change container-cell relationship with binding (:=) and
cell-value relationship with assignment (=).
OK, that's a nice mnemonic. But it need not be implemented
that way---in particular after optimization.
I would consistently dispatch *all* operators including
:=, = and =:=. Preferably at compile/check time. Container
types are then on the same level as any other parametric
type. This naturally explains why your is IType can
be changed like underwear. For the type system it is just
another mutator. Whatever it does to the tied object takes
effect only by changing the type and hence the methods which
are applicable.
Again, please annotate your idea with code. For scalars, I cannot see
how and assignment are supposed to be dispatched to the same
underlying object. It seems to me that:
$x := $y
and
$x = $y
are manipulating two different entities, as I have shown in the drawing.
First of all there are *two* different multi-methods/operators. Usually they
have more than one implementation each. Also the two expressions $x and $y
can be typed. The very least that is known about them is that they are
Items. The compiler than produces code that dispatches to
infix:{'='}:(Item,Item) and infix:{':='}:(Item,Item) repectively.
A generic implementation of = might just end up as:
::Item::x::STORE( ::Item::y::FETCH() );
OTOH, $x := $y hints to the compiler that from here on the user is
not interested in the thing $x represented until now and use only
::Item::y where $x is in the code. If $x is located in a non-transient
position in the namespace it shall represent some kind of link from
there to where $y refers. This might end up as:
::Item::x::LINK( ::Item::y::FETCH() );
I would also like to know how the perl 5 idea of tie can be explained
with coercing the variable into another parametric type. It seems to
me that tie() is a runtime operation that associates a cell with an
object, and the concrete object then intercepts access into that cell.
Well, yes I think it's a multi method with two invocants a cell and an
object in your picture. What it does to these two is up to the one
implementing the method, as usual ;)
And the cell and the object might have an opinion to what extent
they cooperate 8)
Of course at one level there has to exist a low-level protocol that
Perl6 is compiled down to. And I thought this is what PIL is? So
essentially it boils down to presribing some names like STORE, FETCH,
ENTER, LEAVE etc. and using them in some least specific operator
implementations. Implementations on the VM
Re: Container model - pictures and questions
HaloO, Autrijus Tang wrote: The first one is about the compilation cycle: http://pugscode.org/images/simple-compilation.png Question: where is the namespace in the picture? I would expect it to be build in parallel to the syntax tree between parser and compiler. From there it might be serialized like PIL itself? Or as part of it? Only the Target Code Emitters might strip it if the target doesn't need or support it. -- $TSa.greeting := HaloO; # mind the echo!
Re: Container model - pictures and questions
On Tue, Aug 09, 2005 at 02:06:58PM +0200, TSa wrote: The first one is about the compilation cycle: http://pugscode.org/images/simple-compilation.png Question: where is the namespace in the picture? I would expect it to be build in parallel to the syntax tree between parser and compiler. From there it might be serialized like PIL itself? Or as part of it? Only the Target Code Emitters might strip it if the target doesn't need or support it. Packages, aka namespaces, are mutable pointers from names to pads. They are emitted as part of PIL structure. Also, thanks for the earlier suggestion about modeling container types as parametric types; it's indeed a valid suggestion and I'll try to use that idea in my current prototype. Will write more when I get the automatic insertion of coercion statements working. Thanks, /Autrijus/ pgpY6xQwewF3p.pgp Description: PGP signature
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Stevan, Up until today, I thought I had a good idea of how your metamodel works, but now I'm confused. My main sticking point is that a class Foo seems to have three different aspects: Foo class(Foo) meta(Foo) For each of these, could you please try to explain: 1) Roughly what its responsibility is (and how it relates to the others) 2) Whether it is actually an object 3) If so, what its class is I realise that some of these details are probably spread around Synopses, source code, and the inside of your own head, but it would really help to have a concise, clear definition of each. So far, this is what I have picked up; some/most of it is probably wrong: ~ Foo ~ Is a type that variables etc. can be declared to have Is not an object = I'm really not sure about this... ~ class(Foo) ~ Used as the invocant of class methods = Any other purpose? Is an object; instance of the 'Class' class = How do we get properly-typed access to members that class(Foo) has that aren't declared in 'Class'? ~ meta(Foo) ~ Members contain info /about/ Foo, rather than /of/ Foo = This is to avoid name-clashes with 'name', 'authority' etc. Is an object; instance of the 'MetaClass' class Thanks, Stuart
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Guten Tag Herr Sandlaß, On Aug 9, 2005, at 4:48 AM, TSa (Thomas Sandlaß) wrote: HaloO, Stevan Little wrote: Here is a 10,000 ft view of the metamodel prototype I sketched out the other day (http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/ 10_000_ft_view.pod). It should shed a little light on this discussion. There you have i(Foo) - instance of Foo Foo- the user-level Foo class class(Foo) - the instance of Perl6::Class named Foo meta(Foo) - the instance of Perl6::MetaClass which describes Foo The thing which is clear to everybody---even including stupid me---is that there is a 1:n relation between Foo and i(Foo). But then comes a three part referential chain Foo - class(Foo) -- meta(Foo) that to me is conceptually *one* thing. The levels of indirection are implementation details, right? Yes, and no. Please see the second email I sent to Mark. It explains the role I see for ::Class instances, and why they are not just ::MetaClass instances. Also please keep in mind that I am an implementation monkey, and so most anything I am documenting is likely to be the implementation and not the theory. So assuming things are implementation details is usually the right assumption :) The next level where a 1:n relation exists is below meta(Foo) to pure meta. Not entirely, class models are not as neat and tidy as type models, you have many more cycles. To start with, meta(MetaClass) is an instance of MetaClass (this is the traditional object model cycle), it is also a subclass of Object, and then meta(Object) is also an instance of MetaClass. --- is subclass of ... is instance of meta(MetaClass) : ^ : : V : MetaClass -+ ^ | : | : | meta(Object)| ^ | : | : | Object --+ However since this is cyclical, you end up with the Which came first, the chicken of the egg? issue. So in the implementation I have created, the X instance of X part is accomplished through a has-a relationship with the ::Class intsances, so that a ::Foo instance has-a ::Class instance which has-a ::MetaClass instance. Throw in some AUTOLOAD trickery and you have a prototype. Am I missing something? Conceptually I see *one* MetaClass which manages its class instances which in turn manage their object instances. No, there is no *one* MetaClass to manage them all. AFAIK this was something they tried with Smalltalk 72 and found it was problematic, so they went to the every Class instance has a MetaClass instance and things worked out much better. However since I was not alive (and certainly not programming) in '72 I cannot give you any more details that that. OK, it's slightly more complicated because classes can have class instances That does not make it any more complicated. If you think of ::Class instances as being like regular instances, only just acting upon the class level methods and attributes, you can see that things are pretty consistent. and there is multiple inheritance that adds edges into the tree which transform it into a DAG. Nothing in an object model is ever a DAG, there are always cycles. And MI does not complicate things either, a MetaClass just holds a list of superclasses, thats it, nothing more. And I see also classless objects. Yes, but those are not going to be handled in the meta-model, because the meta-model is all about classes. You can however, build a classless system on top of the metamodel, using classes of course. Ahhh, the circularity of it all :) Once you get used it it, it is really a beautiful thing. - Stevan -- $TSa.greeting := HaloO; # mind the echo!
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
HaloO,
Stuart Cook wrote:
So far, this is what I have picked up; some/most of it is probably wrong:
At least your confusion matches nicely with mine :)
~ Foo ~
Is a type that variables etc. can be declared to have
Is not an object
= I'm really not sure about this...
Bare Foo is a namespace lookup. The associated type
is something like 'direct instance of Foo'. It is
checked with the .does method. This type is then
used as type parameter to constrain one of the Fantastic
Four ($@%):
my Foo $foo; # $foo now of type 'Undef of Foo'
foo = Foo.new; # type correct because Foo.new.does(Foo)
~ class(Foo) ~
Used as the invocant of class methods
= Any other purpose?
Is an object; instance of the 'Class' class
From the type system point of view class(Foo) is a Class type.
But that is what bare Foo means anyway if the innermost entry
in the namespace was generated from the class special form.
= How do we get properly-typed access to members that class(Foo) has
that aren't declared in 'Class'?
Sorry, I don't understand that. What do you want to access?
Private class data? Or even lower level implementation details?
Everything else should be accessible through namespace syntax:
Foo::action(); # action call through Code ref
$Foo::attr; # data slot access
@Foo::attr[42] # array slot
given Foo # binds block owner $/ to Foo, $_ from outside
{
::action(); # action() etc. work as well
$::attr;
@::attr[42];
# or with my idea of slot accessor expressions
# bound through $/ := Foo
.action();
$.attr;
@.attr[42];
# or with method dispatch that does not necessarily
# end up calling a slot in Foo
my method action # hide OUTER::action
{
say no Foo method but invocant.does(Foo) is $/.does(Foo);
# what would next METHOD call here?
}
# Note that 'my multi method action' would temporarily install
# action in an existing outer multi or create a new local one and
# and install an outer non-multi in it or some such.
# I'm not the dispatch Guru ;)
.action(); # prints no Foo method but invocant.does(Foo) is true
.attr; # MMD could select Foo::Item::attr accessor
.attr[42]; # MMD could select postfix:[ ](Foo::Array::attr, 42)
}
~ meta(Foo) ~
Members contain info /about/ Foo, rather than /of/ Foo
= This is to avoid name-clashes with 'name', 'authority' etc.
Is an object; instance of the 'MetaClass' class
If avoiding name clashes is all, a simple Foo::META pseudo
namespace and %META hash would do. Why a MetaClass and instances of it?
I hope that .isa, .does and .meta are normal Method subtypes and *not*
slots on some implementation objects/structures.
--
$TSa.greeting := HaloO; # mind the echo!
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
HaloO Stevan, you wrote: Guten Tag Herr Sandlaß, you know that a formal German greeting in a collequial environment can be interpreted as unfriendly? I don't do that but just wanted to state the fact. The next level where a 1:n relation exists is below meta(Foo) to pure meta. Not entirely, class models are not as neat and tidy as type models, you have many more cycles. To start with, meta(MetaClass) is an instance of MetaClass (this is the traditional object model cycle), it is also a subclass of Object, and then meta(Object) is also an instance of MetaClass. --- is subclass of ... is instance of I'm not a good meta modeler---actually I'm none at all. But I get as much as that you built a referential fabric between five data structures. Some of them are used for walking 'up the instanciation chains' and the other for hangling along the 'subclassing links'. But what exactly is the difference between these two? What are they used for? meta(MetaClass) : ^ : : V : MetaClass -+ ^ | : | : | meta(Object)| ^ | : | : | Object --+ However since this is cyclical, you end up with the Which came first, the chicken of the egg? issue. So in the implementation I have created, the X instance of X part is accomplished through a has-a relationship with the ::Class intsances, so that a ::Foo instance has-a ::Class instance which has-a ::MetaClass instance. Throw in some AUTOLOAD trickery and you have a prototype. So, you basically create the gang of five above from the outside and link them together. I've no problem with that. Am I missing something? Conceptually I see *one* MetaClass which manages its class instances which in turn manage their object instances. No, there is no *one* MetaClass to manage them all. AFAIK this was something they tried with Smalltalk 72 and found it was problematic, so they went to the every Class instance has a MetaClass instance and things worked out much better. However since I was not alive (and certainly not programming) in '72 I cannot give you any more details that that. But Smalltalk is a typeless language that dispatches along the lines of the (meta)class/(meta)object links. I propose to call this kind of thing slot dispatch and reserve single and multi method dispatch for the type based approach. Don't get me wrong, I consider them all as equally usefull tools that belong into a state of the art programming language. The only question is which gets the nicest syntax. And I guess the meta model by its nature of beeing 'behind the illusion of simplicity' has to take the burden of beeing somewhat uglier or more verbose or some such. OK, it's slightly more complicated because classes can have class instances That does not make it any more complicated. If you think of ::Class instances as being like regular instances, only just acting upon the class level methods and attributes, you can see that things are pretty consistent. Hmm, again: what distinguishes classes from objects and meta classes from meta objects? I mean other then beeing different nodes in a referential fabric? BTW, is there a good name for it? I guess Matrix is also over-used. My view is that Perl6 should have a name tree, a type lattice and a meta graph/model/fabric? and there is multiple inheritance that adds edges into the tree which transform it into a DAG. Nothing in an object model is ever a DAG, there are always cycles. And MI does not complicate things either, a MetaClass just holds a list of superclasses, thats it, nothing more. And I see also classless objects. Yes, but those are not going to be handled in the meta-model, because the meta-model is all about classes. You can however, build a classless system on top of the metamodel, using classes of course. Could it be the case that choosing the same terms 'class' and 'object' on the meta level as on the user level is a *bad* idea? At least it will be a source of confusion. Ahhh, the circularity of it all :) What is the benefit of the circularity? Once you get used it it, it is really a beautiful thing. Infinite recursion is a great mental tool, indeed. But somewhat difficult to implement without either infinite processing time or infinite memory :) -- $TSa.greeting := HaloO; # mind the echo!
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
On Tue, Aug 09, 2005 at 06:36:28PM +0200, TSa wrote: But Smalltalk is a typeless language that dispatches along the lines of the (meta)class/(meta)object links. I propose to call this kind of thing slot dispatch and reserve single and multi method dispatch for the type based approach. Don't get me wrong, I consider them all as equally usefull tools that belong into a state of the art programming language. The only question is which gets the nicest syntax. And I guess the meta model by its nature of beeing 'behind the illusion of simplicity' has to take the burden of beeing somewhat uglier or more verbose or some such. Perl 6 in its unannotated form is also (mostly) a typeless languages, with only the five builtin types, much like Perl 5 is. I suspect that the unannotated form will be the form most program begins, which is why they are (naturally) shorter than annotated forms. As you add more types and turn on optimization settings, the inferencer/typechecker kicks in, and you get more static bindings; however, the metamodel still exist at runtime, and it is with it that most runtime reflection is performed. Yes, but those are not going to be handled in the meta-model, because the meta-model is all about classes. You can however, build a classless system on top of the metamodel, using classes of course. Could it be the case that choosing the same terms 'class' and 'object' on the meta level as on the user level is a *bad* idea? At least it will be a source of confusion. I think the meta- prefix is what caused much of the initial conclusion. When I first heard metatheory, I also thought it was some kind of ontological mystery. Turns out that meta in this context coincides with guts, as in perlguts -- i.e., something that happens at the internals level. So, think of them more like Internal Objects and Internal Classes, or Object Guts and Class Guts... Ahhh, the circularity of it all :) What is the benefit of the circularity? The benefit is that the implementor won't need to implement a countless set of turtles all the way down. :) Once you get used it it, it is really a beautiful thing. Infinite recursion is a great mental tool, indeed. But somewhat difficult to implement without either infinite processing time or infinite memory :) Nah, lazy evaluation is the canonical solution to this! (Sorry, can't resist it.) Thanks, /Autrijus/ pgp1zfTJA17vU.pgp Description: PGP signature
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Stuart, On Aug 9, 2005, at 9:25 AM, Stuart Cook wrote: Stevan, Up until today, I thought I had a good idea of how your metamodel works, but now I'm confused. My main sticking point is that a class Foo seems to have three different aspects: Foo class(Foo) meta(Foo) For each of these, could you please try to explain: 1) Roughly what its responsibility is (and how it relates to the others) 2) Whether it is actually an object 3) If so, what its class is I will simply add to your explanations below (the are mostly correct). Keep in mind, as I said to TSa, I am coming from a implementation point of view, and so much of what I descibe will be about the implementation. I realise that some of these details are probably spread around Synopses, source code, and the inside of your own head, but it would really help to have a concise, clear definition of each. Yes, sorry. This is why I am trying to document it now. So far, this is what I have picked up; some/most of it is probably wrong: ~ Foo ~ Is a type that variables etc. can be declared to have That is one way to look at it I suppose. The reality is that there will be no actual 'Foo', at least not in the metamodel. 'Foo' is a magical interpreter concept, which is really just an alias/pointer/level-of-indirection/whatever for class(Foo). This is all, of course, implementation details. Is not an object Nope... its magic :) = I'm really not sure about this... ahh, but you were correct. Trust your instincts Stuart the force is strong with this one I think ~ class(Foo) ~ Used as the invocant of class methods Yes. It is also the connection between the concrete instance and concrete metaclass instance. = Any other purpose? In autrijus's version of the model it also stores the index of the attribute in the instance storage array. But other than that, no it has no other purpose in my eyes. Is an object; instance of the 'Class' class Perl6::Class in the p5 metamodel. I also find adding either the Perl6:: or just :: at the front of names like 'Class' are helpful. = How do we get properly-typed access to members that class(Foo) has that aren't declared in 'Class'? class(Foo) instance methods will be for 'Foo', and the class methods will be for ::Class. The current metamodel hacks this in a kind of ugly way, but that is how I am seeing it. ~ meta(Foo) ~ Members contain info /about/ Foo, rather than /of/ Foo Yes, the metaclass basically stores the name, version, authority, superclass list, private method table, public method table and attribute list. All the things which make up a class (yes, I am fluffing the details here a bit, but you get the idea). = This is to avoid name-clashes with 'name', 'authority' etc. That is not really the reason, but yes it does mean that there are no restrictions placed on class methods for 'Foo'. Is an object; instance of the 'MetaClass' class Yes sir. That is correct. All in all Stuart, you were pretty much right on. Stevan Thanks, Stuart
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
On Aug 9, 2005, at 12:36 PM, TSa wrote: HaloO Stevan, you wrote: Guten Tag Herr Sandlaß, you know that a formal German greeting in a collequial environment can be interpreted as unfriendly? I don't do that but just wanted to state the fact. My apologies, no unfriendliness intended :) The next level where a 1:n relation exists is below meta(Foo) to pure meta. Not entirely, class models are not as neat and tidy as type models, you have many more cycles. To start with, meta(MetaClass) is an instance of MetaClass (this is the traditional object model cycle), it is also a subclass of Object, and then meta(Object) is also an instance of MetaClass. --- is subclass of ... is instance of I'm not a good meta modeler---actually I'm none at all. They are icky beasts and can cause ulcers, I suggest avoiding them at all costs :) But I get as much as that you built a referential fabric between five data structures. Some of them are used for walking 'up the instanciation chains' and the other for hangling along the 'subclassing links'. But what exactly is the difference between these two? What are they used for? Actually I think it is 4 data structures, if I understand your question correctly. 1) the instance, 2) the magic 'Foo' class, 3) the class(Foo) (is instance of Perl6::Class) and 4) meta(Foo) (an instance of Perl6::MetaClass). They are mostly used for walking 'up the instanciation chains' for things like; - to collect all relevant attributes - method dispatch - ordered destruction - etc. I do not hangle along the 'subclass links' because I actually don't store subclass links. I considered adding them, but to be honest, I have yet to encounter a real use for them short of introspection. However since this is cyclical, you end up with the Which came first, the chicken of the egg? issue. So in the implementation I have created, the X instance of X part is accomplished through a has-a relationship with the ::Class intsances, so that a ::Foo instance has-a ::Class instance which has-a ::MetaClass instance. Throw in some AUTOLOAD trickery and you have a prototype. So, you basically create the gang of five above from the outside and link them together. I've no problem with that. Yes, basically, this is the bootstrapping code. It is the ugly underbelly of the metamodel. Am I missing something? Conceptually I see *one* MetaClass which manages its class instances which in turn manage their object instances. No, there is no *one* MetaClass to manage them all. AFAIK this was something they tried with Smalltalk 72 and found it was problematic, so they went to the every Class instance has a MetaClass instance and things worked out much better. However since I was not alive (and certainly not programming) in '72 I cannot give you any more details that that. But Smalltalk is a typeless language that dispatches along the lines of the (meta)class/(meta)object links. I propose to call this kind of thing slot dispatch and reserve single and multi method dispatch for the type based approach. Don't get me wrong, I consider them all as equally usefull tools that belong into a state of the art programming language. The only question is which gets the nicest syntax. And I guess the meta model by its nature of beeing 'behind the illusion of simplicity' has to take the burden of beeing somewhat uglier or more verbose or some such. Yes, the metamodel will surely have many ugly and verbose corners. This is expected for bootstrapping a reflective metamodel of this kind. As for your dispatch-ing point. I am not sure I understand what you are saying, it seems almost as if you are arguing for a generic-function approach like CLOS/Dylan rather than a methods-stored-in-class approach like most mainstream OO. Is that correct, or am I reading in too far? IMO, generic functions are really really really really nice things. However, they are hard to understand for most programmers, so they are not really viable (unless you hide them under a nice UI). OK, it's slightly more complicated because classes can have class instances That does not make it any more complicated. If you think of ::Class instances as being like regular instances, only just acting upon the class level methods and attributes, you can see that things are pretty consistent. Hmm, again: what distinguishes classes from objects and meta classes from meta objects? Nothing, everything is an Object (for the most part, that is). The distinction between meta-level and user-level (or as they call it in The Art of MOP, backstage and on-stage) is really an artificial barrier which the interpreter sets up. The purpose of the meta-object protocol is to document how much of the backstage is actually visible from on-stage. I mean other then beeing different nodes in a referential fabric? BTW, is there a good name for it? I guess Matrix is also over-used. My view is that Perl6 should have a name tree, a
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
On Aug 9, 2005, at 10:52 AM, TSa wrote:
~ Foo ~
Is a type that variables etc. can be declared to have
Is not an object
= I'm really not sure about this...
Bare Foo is a namespace lookup.
Yes, TSa is right. Everything below this is Type-stuff and I will leave
that to him (up until the Meta part that is).
The associated type
is something like 'direct instance of Foo'. It is
checked with the .does method. This type is then
used as type parameter to constrain one of the Fantastic
Four ($@%):
my Foo $foo; # $foo now of type 'Undef of Foo'
foo = Foo.new; # type correct because Foo.new.does(Foo)
~ class(Foo) ~
Used as the invocant of class methods
= Any other purpose?
Is an object; instance of the 'Class' class
From the type system point of view class(Foo) is a Class type.
But that is what bare Foo means anyway if the innermost entry
in the namespace was generated from the class special form.
= How do we get properly-typed access to members that class(Foo)
has
that aren't declared in 'Class'?
Sorry, I don't understand that. What do you want to access?
Private class data? Or even lower level implementation details?
Everything else should be accessible through namespace syntax:
Foo::action(); # action call through Code ref
$Foo::attr; # data slot access
@Foo::attr[42] # array slot
given Foo # binds block owner $/ to Foo, $_ from outside
{
::action(); # action() etc. work as well
$::attr;
@::attr[42];
# or with my idea of slot accessor expressions
# bound through $/ := Foo
.action();
$.attr;
@.attr[42];
# or with method dispatch that does not necessarily
# end up calling a slot in Foo
my method action # hide OUTER::action
{
say no Foo method but invocant.does(Foo) is $/.does(Foo);
# what would next METHOD call here?
}
# Note that 'my multi method action' would temporarily install
# action in an existing outer multi or create a new local one and
# and install an outer non-multi in it or some such.
# I'm not the dispatch Guru ;)
.action(); # prints no Foo method but invocant.does(Foo) is true
.attr; # MMD could select Foo::Item::attr accessor
.attr[42]; # MMD could select postfix:[ ](Foo::Array::attr, 42)
}
~ meta(Foo) ~
Members contain info /about/ Foo, rather than /of/ Foo
= This is to avoid name-clashes with 'name', 'authority' etc.
Is an object; instance of the 'MetaClass' class
If avoiding name clashes is all, a simple Foo::META pseudo
namespace and %META hash would do. Why a MetaClass and instances of it?
Avoiding name clashes is one point, and I tried the Foo::META thing at
one point. Actually the current meta-model grew out of that early
prototype, but soon it outgrew that. IIRC it lead to a lot of code
duplication, which likely was an implementation detail.
I hope that .isa, .does and .meta are normal Method subtypes and *not*
slots on some implementation objects/structures.
I am not sure I understand this. Can you elaborate?
Stevan
--
$TSa.greeting := HaloO; # mind the echo!
$object.meta.isa(?) redux
Howdy, I wanted to make sure this question had a chance to get addressed, so I am seperating it from the other thread which has digressed into the depths of the metamodel (much to my delight too). So..., as described in the other thread, the following statements are true about the metamodel. 1) MetaClass is a subclass of Object 2) MetaClass is an instance of MetaClass So the following code should be true (given a random instance $obj). $obj.meta.isa(MetaClass); $obj.meta.isa(Object); Because after all, the object returned from $obj.meta should be a MetaClass instance right? However, Syn/Apoc 12 shows that the following is true if $foo is an instance of the Foo class. $foo.meta.isa(Foo) And that $foo.isa(Foo) actually is just an alias for $foo.meta.isa(Foo). So I am sure you can see my problem here. The p5 prototype currently handles it as such: $foo-isa(Foo) # returns true if $foo is an instance of Foo $foo-meta-isa(MetaClass) # returns true since $foo-meta returns a MetaClass instance $foo-meta-is_a(Foo) # returns true, note the added '_' Personally I am not a fan of the 'is_a' name, I just did it one day, and it sort of stuck. But I do think we need to find a way to differentiate between the two questions: - What class are you an instance of? - What class are you describing? The first question can be asked of anything which inherits from Object. The second question is really only relevant to MetaClass instances. Thoughts, Comments, Suggestions? Thanks, - Stevan
Re: $object.meta.isa(?) redux
On Tue, Aug 09, 2005 at 05:08:43PM -0400, Stevan Little wrote: : Howdy, : : I wanted to make sure this question had a chance to get addressed, so I : am seperating it from the other thread which has digressed into the : depths of the metamodel (much to my delight too). : : So..., as described in the other thread, the following statements are : true about the metamodel. : : 1) MetaClass is a subclass of Object : 2) MetaClass is an instance of MetaClass : : So the following code should be true (given a random instance $obj). : : $obj.meta.isa(MetaClass); : $obj.meta.isa(Object); : : Because after all, the object returned from $obj.meta should be a : MetaClass instance right? : : However, Syn/Apoc 12 shows that the following is true if $foo is an : instance of the Foo class. : : $foo.meta.isa(Foo) : : And that $foo.isa(Foo) actually is just an alias for $foo.meta.isa(Foo). The A12 verbiage was intended to indicate delegation rather than aliasing, so there's certainly room for calling a different method name in the meta class. : So I am sure you can see my problem here. : : The p5 prototype currently handles it as such: : : $foo-isa(Foo) # returns true if $foo is an instance of Foo : $foo-meta-isa(MetaClass) # returns true since $foo-meta returns a : MetaClass instance : $foo-meta-is_a(Foo) # returns true, note the added '_' : : Personally I am not a fan of the 'is_a' name, I just did it one day, : and it sort of stuck. Well, hey, I'm not a fan of the isa name, so I guess we're even. : But I do think we need to find a way to : differentiate between the two questions: : : - What class are you an instance of? : - What class are you describing? So why not just use describes? Then maybe Object.isa(Foo) delegates to $obj.meta.describes(Foo). : The first question can be asked of anything which inherits from Object. : The second question is really only relevant to MetaClass instances. : : Thoughts, Comments, Suggestions? My suggestion would be to assume that the Apocalypses are primarily intended to be entertaining rather than factual. :-) Larry
$obj.meta.add_method('foo' = ???)
More MOP related questions :)
In the p5 MetaModel, you can do the following:
$obj-meta-add_method('foo' =
Perl6::Method-create_instance_method(sub { ... }));
$obj-meta-add_method('foo' = Perl6::Method-create_class_method(sub
{ ... }));
$obj-meta-add_method('foo' = Perl6::Method-create_submethod(sub {
... }));
$obj-meta-add_method('foo' =
Perl6::Method-create_private_method(sub { ... }));
quick aside for clarity
The Perl6::Method package is really just a closure generator. It takes
a chunk of code (a sub {} ref) and wraps it with the appropriate
wrapper based on the type of method-thing you request. It currently
handles instance methods, class methods, private methods and
submethods. The details of this are not really relevant to this
discussion though, I just wanted to answer what I saw as an inevitable
question.
/quick aside for clarity
Now I realize that in perl 6 you can re-open classes and add methods to
them. However this is not convenient for programmatic class generation.
And I would really prefer the old Perl 5 way of mucking with the symbol
table not be the Perl 6 way of doing this. The ideal approach IMO is to
be able to do what the p5 MetaModel prototype does, and be able to add
methods to the metaclass instance directly (which then exposes them to
the class and instances of the class).
So, how should this look in Perl 6? I currently have a two
thoughts/suggestions/directions.
1) Anonymous methods/submethods
$obj.meta.add_method('foo' = method (Foo $self: $bar) { ... });#
adding an instance method
$obj.meta.add_method('foo' = method (::Foo $class: $bar) { ... }); #
adding a class method
$obj.meta.add_method('foo' = submethod ($self: $bar) { ... }); #
adding a submethod method
$obj.meta.add_method(':foo' = method ($self: $bar) { ... }); #
adding a private method (NOTE: ':' in name)
I am not sure if anonymous methods have been discussed already or not.
But this is one possible approach. The idea being that since it is a
method already, it would already know about things like $?SELF, $?CLASS
and next METHOD (although those values would be unbound), and would
likely have an invocant parameter (which could sometimes be used to
determine if it was a class method or instance method).
2) Closure factory
$obj.meta.add_method('foo' = sub ($self, $bar) { ... },
:typeinstance);
$obj.meta.add_method('foo' = sub ($self, $bar) { ... }, :typeclass);
$obj.meta.add_method('foo' = ($self, $bar) - { ... },
:typesubmethod);
$obj.meta.add_method(':foo' = { ... }, :typeprivate);
Given an arbitrary block of executable code (anything from a raw block,
to a pointy block, to a sub ref) the add_method closure factory will
turn it into the right method-thing based upon the :type parameter.
Thoughts??
Thanks,
Stevan
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
On Tue, Aug 09, 2005 at 03:54:23PM -0400, Stevan Little wrote: : Stuart, : : On Aug 9, 2005, at 9:25 AM, Stuart Cook wrote: : Stevan, : : Up until today, I thought I had a good idea of how your metamodel : works, but now I'm confused. My main sticking point is that a class : Foo seems to have three different aspects: : : Foo : class(Foo) : meta(Foo) : : For each of these, could you please try to explain: : 1) Roughly what its responsibility is (and how it relates to the : others) : 2) Whether it is actually an object : 3) If so, what its class is : : I will simply add to your explanations below (the are mostly correct). : Keep in mind, as I said to TSa, I am coming from a implementation point : of view, and so much of what I descibe will be about the : implementation. And I will comment from the language point of view. : I realise that some of these details are probably spread around : Synopses, source code, and the inside of your own head, but it would : really help to have a concise, clear definition of each. : : Yes, sorry. This is why I am trying to document it now. : : : So far, this is what I have picked up; some/most of it is probably : wrong: : : ~ Foo ~ : Is a type that variables etc. can be declared to have : : That is one way to look at it I suppose. The reality is that there will : be no actual 'Foo', at least not in the metamodel. 'Foo' is a magical : interpreter concept, which is really just an : alias/pointer/level-of-indirection/whatever for class(Foo). Well, Perl 6 The Language sees Foo as package(Foo), actually. : This is all, of course, implementation details. When Perl 6 The Language sees any bare identifier, it cannot treat it as a bareword like Perl 5 does, since Perl 6 has no barewords. So either something in the context tells us what Foo means, or it will be taken as a list operator that hasn't been declared yet. There are various nearby contextualizers, such as an immediately preceding sub or an immediately following ( or =. Distant context basically comes down to declarations that influence the langauge that is recognized at the current location, and a class declaration is just one of those kinds of declaration. : Is not an object : : Nope... its magic :) Well, hmm, except insofar as any package is an object that knows how to be a symbol table, and and be the base class for other kinds of more magical packages. The magic comes into play when these various package objects start pretending to be modules or classes or roles or subtypes. : = I'm really not sure about this... : : ahh, but you were correct. Trust your instincts Stuart the force is : strong with this one I think Yes, you're basically correct. It's just that Perl 6 The Language thinks that all types are interfaces and thus stored in various kinds of packages, many of which have public names, though there are also anonymous and lexical packages/modules/classes/roles/types. : ~ class(Foo) ~ : Used as the invocant of class methods : : Yes. It is also the connection between the concrete instance and : concrete metaclass instance. : : = Any other purpose? : : In autrijus's version of the model it also stores the index of the : attribute in the instance storage array. But other than that, no it has : no other purpose in my eyes. From the viewpoint of Perl 6 The Language, a class also serves as the generic placeholder for reasoning about objects of the class in the abstract without necessarily actually having an object of that type to play with. As such it's the logical invocant for constructors, as well as other methods that want to play what if games on the objects of the class without necessarily creating one. Some of these abstract games will naturally call into the guts of the metaclass for answers. For example, you might ask the class an abstract question: If I were to ask each existing object whether it thinks it's a member of your class, how many would say 'yes'? Of course, the efficient way to answer that question is probably not to interrogate all the objects, but just cheat somehow via the metaobject. I kinda like Autrijus's idea that meta just means guts. In classical Greek, meta just means with. The fancy philosophical meaning of aboutness isn't there, but is a backformation from terms such as metaphysics. Metaphysics is just what you study along with physics. Though guts objects is a bit offputting. You know, I keep mistyping meta as meat half the time, so maybe we should make that a feature and call them meat objects instead. :-) Except that then I'd be typing meat as meta half the time... : Is an object; instance of the 'Class' class : : Perl6::Class in the p5 metamodel. I also find adding either the Perl6:: : or just :: at the front of names like 'Class' are helpful. : : = How do we get properly-typed access to members that class(Foo) has : that aren't declared in 'Class'? : : class(Foo) instance methods will be for 'Foo', and the class
Re: $object.meta.isa(?) redux
Larry, On Aug 9, 2005, at 6:18 PM, Larry Wall wrote: : Personally I am not a fan of the 'is_a' name, I just did it one day, : and it sort of stuck. Well, hey, I'm not a fan of the isa name, so I guess we're even. fair enough :) : But I do think we need to find a way to : differentiate between the two questions: : : - What class are you an instance of? : - What class are you describing? So why not just use describes? Then maybe Object.isa(Foo) delegates to $obj.meta.describes(Foo). I like that, but is it appropriate for subclasses as well? Or should Object.isa(Foo) just use WALKCLASS and check the hierarchy itself using .describes()? : The first question can be asked of anything which inherits from Object. : The second question is really only relevant to MetaClass instances. : : Thoughts, Comments, Suggestions? My suggestion would be to assume that the Apocalypses are primarily intended to be entertaining rather than factual. :-) Already assumed :) However, I need to start somewhere. Thanks, Stevan
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Larry, On Aug 9, 2005, at 7:19 PM, Larry Wall wrote: : So far, this is what I have picked up; some/most of it is probably : wrong: : : ~ Foo ~ : Is a type that variables etc. can be declared to have : : That is one way to look at it I suppose. The reality is that there will : be no actual 'Foo', at least not in the metamodel. 'Foo' is a magical : interpreter concept, which is really just an : alias/pointer/level-of-indirection/whatever for class(Foo). Well, Perl 6 The Language sees Foo as package(Foo), actually. IIRC, autrijus said that one of the base concepts in PIL was a namespace (which is roughly equivalent to a package). So I have assumed in my metamodel (and mostly in recent refactorings) that the magic behind Foo would have something to do with packages/namespaces. So this aligns nicely with your view. : Is not an object : : Nope... its magic :) Well, hmm, except insofar as any package is an object that knows how to be a symbol table, and and be the base class for other kinds of more magical packages. The magic comes into play when these various package objects start pretending to be modules or classes or roles or subtypes. Let me make sure I understand this. Package is an Object. Module is a Package. Class is a Package. Role is a Package. (I wont even go near subtypes as I dont completely understand them). But is Perl6::Class (the Class class) also a Package? Or is Foo the Package in this picture? If Foo is the Package, then it would then be possible to implement this system on-top of the metamodel? If Perl6::Class is also a package, then we have a potential bootstrap issue. : = I'm really not sure about this... : : ahh, but you were correct. Trust your instincts Stuart the force is : strong with this one I think Yes, you're basically correct. It's just that Perl 6 The Language thinks that all types are interfaces and thus stored in various kinds of packages, many of which have public names, though there are also anonymous and lexical packages/modules/classes/roles/types. : ~ class(Foo) ~ : Used as the invocant of class methods : : Yes. It is also the connection between the concrete instance and : concrete metaclass instance. : : = Any other purpose? : : In autrijus's version of the model it also stores the index of the : attribute in the instance storage array. But other than that, no it has : no other purpose in my eyes. From the viewpoint of Perl 6 The Language, a class also serves as the generic placeholder for reasoning about objects of the class in the abstract without necessarily actually having an object of that type to play with. As such it's the logical invocant for constructors, as well as other methods that want to play what if games on the objects of the class without necessarily creating one. Some of these abstract games will naturally call into the guts of the metaclass for answers. For example, you might ask the class an abstract question: If I were to ask each existing object whether it thinks it's a member of your class, how many would say 'yes'? Of course, the efficient way to answer that question is probably not to interrogate all the objects, but just cheat somehow via the metaobject. I see all these methods of interrogation as being class methods defined in the base Object. Would that be correct? I kinda like Autrijus's idea that meta just means guts. In classical Greek, meta just means with. The fancy philosophical meaning of aboutness isn't there, but is a backformation from terms such as metaphysics. Metaphysics is just what you study along with physics. Though guts objects is a bit offputting. You know, I keep mistyping meta as meat half the time, so maybe we should make that a feature and call them meat objects instead. :-) Except that then I'd be typing meat as meta half the time... GutClass is kinda gross. I personally like the metaphors in The Art of MOP, which are backstage objects/classes and on-stage objects/classes. The only thing that seperates them is the curtain, and even that can be pulled away to expose more, but is always in control of the backstage crew (aka the language implementors). : Is an object; instance of the 'Class' class : : Perl6::Class in the p5 metamodel. I also find adding either the Perl6:: : or just :: at the front of names like 'Class' are helpful. : : = How do we get properly-typed access to members that class(Foo) has : that aren't declared in 'Class'? : : class(Foo) instance methods will be for 'Foo', and the class methods : will be for ::Class. : : The current metamodel hacks this in a kind of ugly way, but that is how : I am seeing it. I'm not sure if Class is really a class or just a role containing the interface to bootstrap a class instance using the meatclass, er, I mean, the metaclass. The abstract parts of a class that overlie the package are rather, um, abstract. Larry
