Re: Complete type inferencing
HaloO,
Autrijus Tang wrote:
Yes, I'm aware of Theta's static where clauses, but Perl 6's where
clause is much more dynamic and almost always undecidable.
I know, but what does that buy the programmer? I see a type system
as support of a declarative programming style. Thus the dynamic part
of the type system, that is method dispatch and type instanciation,
has to play in a frame set by the programmer. This is very similar to
regular expressions and grammars. They declare the interpretation of
a string/stream of chars/data. The type system goes on from there to
watch over constraints while this data is processed.
In Litvinov's paper, where clauses are determinisitic at compile time,
as a way to encode structural subtyping (aka duck typing).
Huch, who has coined 'duck typing'? I never heard that before.
The important difference is that the .can() call in Perl 6 would be a
runtime call. It has to be that way, because .can is not a special
form; it's just a normal method returning a boolean. If you really
want static treatment, that needs a special form:
sub foo (
$obj can bar:(() returns Int)
) returns Int {
$obj.bar();
}
It will allow constructs such as this:
my subtype Duck
has $.half_life
can doom:()
can quake:(() returns Wolfenstein);
Yes, I like that. I also proposed an object special form for
classless instances in namespace.
# Automagically satisfied iff $obj's interface is compatible
$obj.does(Duck);
Such implicitly-declared Roles is certainly powerful, and we can apply
the same inferencing treatment as for nominal subtyping violations --
fatal error under closed/finalized, raise warning by default.
I think it's cute, and adds real power of row polymorphism to the
What is 'row polymorphism'?
language, iff Perl 6 indeed adopts a compile-time inferencing engine.
I would call it a bit different, but yes please! My idea is, that the
programmer of Perl 6 can 'store' a lot of information in name/type space
that is later---even at runtime---used by the code generation, class
composition, type instanciation and dispatch system without forcing the
programmer to rummage in the guts, which might actually be very difficult
to do platform independently if not even Parrot is fixed as the underlying
VM!
BTW, is 'special form' a fixed term? I just started using it to decribe
things like sub, class, role, etc. declarations/definitions.
--
$TSa.greeting := "HaloO"; # mind the echo!
Translating (or at least parsing) Java interface definitions
Anyone done any work on parsing Java interface definitions? And, ideally, translating them into roughly equivalent Perl 6? Tim.
Re: Elimination of Item|Pair and Any|Junction
HaloO, Autrijus Tang wrote: On Thu, Jul 28, 2005 at 09:27:00AM -0700, Larry Wall wrote: Or maybe Any really does mean "Object" and we're just viewing our hierarchy too strictly if we make every relationship "isa". That's one thing that neither this formulation nor Thomas's are making very clear--which type relations are really subclassing, which are role composition, and which are subtype constraints. Well I would make all types predicate based. The isa relation of an object to the class it was instanciated from is just one amongst many others like doing a role or object structure. And the inheritance hierarchy is mostly irrelevant for typing an object. This is one of the difficulties I have with the metric MMD which relies completely on the count of class derivation levels. I currently have the following model in mind. The compiler collects type information from so-called special forms and stores it in a strictly tree shaped repository called the name space. User code can query this structure by means of the :: forms. The type lattice is then build at CHECK time on top of or from this information. In particular I don't make a distintion between subtype, role, class, sub or method special forms. This implies that where clauses are restricted in the contructs allowed in them and the referential environment accessible to them. FWIW, I've been reading up on Scala's formulation of trait/class/delegation hierarchy, and I feel a bit like flipping through a puzzle book to look at the hints, if not answers. :-) The Scala type hierarchy splits from the Any root into the two realms of value types and referential types in good tradition with Java. This split is located in my type lattice below the $Item type where \Ref, Value, Undef, Inf and Junction lie nicely parallel to each other. -- TSa
Re: Container model - pictures and questions
HaloO, Autrijus Tang wrote: If I'm mistaken, please let me know, preferably by suggesting new arrangements on the diagram. :-) Without judging your mistakes, here are my comments to the container picture. 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. 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. 3) Why is the link from the container labeled with := but the link between the cell and the value with =? 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. -- ::TSa.greeting := "HaloO"; # mind the echo!
Re: Container model - pictures and questions
On Mon, Aug 08, 2005 at 06:04:51PM +0200, "TSa (Thomas Sandla�)" wrote: > Autrijus Tang wrote: > >If I'm mistaken, please let me know, preferably by suggesting > >new arrangements on the diagram. :-) > > Without judging your mistakes, here are my comments to the > container picture. > > 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!? > 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. > 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 (=). >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. 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. Thanks, /Autrijus/ pgpCZrXZWLfie.pgp Description: PGP signature
Perl 6 Meta Object Protocols and $object.meta.isa(?)
Hello All, Since autrijus is now busy porting the P5 metamodel prototype into Haskell for use in Pugs, I have decided to begin work on documenting the Perl6::MetaModel prototype modules more thoroughly. The first step I see in this is to define a Meta Object Protocol (aka - the stuff you can do with/to $obj.meta). I have reviewed the relevant sections in Syn/Apoc 12 and am now writing a small add-on (I am calling it Syn 12.5 for now) which I hope will can augment the relevant sections from Syn/Apoc 12. As soon as the document is complete enough, I will post it here, or you can see it here (http://svn.openfoundry.org/pugs/perl5/Perl6-MetaModel/docs/) as it is being developed. I welcome all comments, questions and suggestions oh, and help too :). This now brings me to the second item mentioned in the subject line. So..., as far as I see it, 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: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Coming in late here, but it seems odd to have an actual class called "MetaClass". The meta-object protocols with which I am familiar have the concept of a metaclass (a class whose instances are themselves classes), and the class Class is such a metaclass, but where does a class named MetaClass fit in? If all metaclasses are instances of MetaClass, then MetaClass must be an instance of itself - is this then the only cycle in the graph? > 1) MetaClass is a subclass of Object > 2) MetaClass is an instance of MetaClass OK. > So the following code should be true (given a random instance $obj). > >$obj.meta.isa(MetaClass); >$obj.meta.isa(Object); What does $obj.meta return - is it just a shortcut for $obj.class.class, or is something else going on here? If the former, then all of these should be true. $obj.isa(Object) $obj.class.isa(Object) $obj.class.isa(Class) $obj.meta.isa(Object) $obj.meta.isa(Class) $obj.meta.isa(MetaClass) > However, Syn/Apoc 12 shows that the following is true if $foo is an > instance of the Foo class. > >$foo.meta.isa(Foo) Hm. That doesn't make sense to me at all. Clearly I need to reread the Syn/Apoc. I'd expect $foo.isa(Foo) and that's it, although if nothing fancy with composition is going on $foo.class == Foo would also be true.
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Mark, On Aug 8, 2005, at 4:26 PM, Mark Reed wrote: Coming in late here, but it seems odd to have an actual class called "MetaClass". The meta-object protocols with which I am familiar have the concept of a metaclass (a class whose instances are themselves classes), and the class Class is such a metaclass, but where does a class named MetaClass fit in? I discussed with Larry at the hackathon about the role that Class played in the metamodel. We decided that is was but a thin veneer between the meta-land and the user-land. I assume this is still the case. 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. As for how this differs from the other MOPs out there. I took the basic design of MetaClass, Class, Object from Smalltalk -80 actually, but modified the relationships a little to be more has-a the is-a. Let me expand/digress on this slightly .. The basic Smalltalk-80 idea of every user-level Class having an associated meta-level Class is still retained. However in Smalltalk, Class is an instance of MetaClass, where in the metamodel Class has-a instance of MetaClass. And as I said, Class is really nothing special, it but a level of indirection between the instance and MetaClass instance. I also borrowed many ideas from CLOS (in particular from book "The Art of the MetaObject Protocol"). CLOS is more like what you describe, where standard-class is the metaobject to define classes. I see this as mapping to the MetaClass, and our Class as being something akin to the find-class generic function in CLOS. If all metaclasses are instances of MetaClass, then MetaClass must be an instance of itself - is this then the only cycle in the graph? Yes, that is the cycle. 1) MetaClass is a subclass of Object 2) MetaClass is an instance of MetaClass OK. So the following code should be true (given a random instance $obj). $obj.meta.isa(MetaClass); $obj.meta.isa(Object); What does $obj.meta return - is it just a shortcut for $obj.class.class, or is something else going on here? Well, I did not see $obj.class speced in A/S12 so I never did anything with that. However the p6opaque instance structure I use in the prototype metamodel has a pointer back to the class object (see the 10,000 ft view again). So it is simple to implement it if we want too. But to answer your question, I was always under the impression that $obj.meta returned the MetaClass instance associated with the class that $obj is an instance of. However, keep in mind, these are somewhat fuzzy areas in Syn/Apoc12, and all details about $obj.meta only deal with "Introspection". Arghhh, these be uncharted waters 'mah Boy! If the former, then all of these should be true. $obj.isa(Object) yup, this will always be true. $obj.class.isa(Object) $obj.class.isa(Class) Again, no .class that I know of, however if there is, then these too should be true. $obj.meta.isa(Object) $obj.meta.isa(Class) $obj.meta.isa(MetaClass) I will agree with 1 and 3, but not with 2. I see Class and MetaClass are seperate things, at least how I coded it. However this, should be true (assuming we introduce a .class method): $obj.meta.class.isa(Class) However this is not a closed issue, so we can discuss it if you see a real need for things to be this way. However, Syn/Apoc 12 shows that the following is true if $foo is an instance of the Foo class. $foo.meta.isa(Foo) Hm. That doesn't make sense to me at all. Clearly I need to reread the Syn/Apoc. I'd expect $foo.isa(Foo) and that's it, although if nothing fancy with composition is going on $foo.class == Foo would also be true. Yup, doesn't make sense to me either :) - Stevan
Re: Perl 6 Meta Object Protocols and $object.meta.isa(?)
Mark, To add to what I explained re: Class objects. We have instance methods and class methods now in Perl 6, as well as instance attributes and class attributes. The way I view Class objects are as such: A Class object is to class methods as an instance is to instance methods. Meaning, the Class object will be invocant of all the class methods. It is of course possible to also then have the metaobject protocol act upon that class object (meaning the methods defined in the meta-object protocol would have the class object as the invocant), but in my mind that could present namespace issues. For instance, the meta-object protocol which is begun in Apoc/Syn 12 talks about a .name, .version and .authority methods. I could see very easily where the meta-object protocol could conflict with user defined class methods of the same name. So by having the Class objects be the invocants for class methods, and the MetaClass objects be the invocants for the methods defined by the meta-object protocol, we are avoiding any namespace clashes. Anyway, just wanted to add that :) - Stevan On Aug 8, 2005, at 5:49 PM, Stevan Little wrote: Mark, On Aug 8, 2005, at 4:26 PM, Mark Reed wrote: Coming in late here, but it seems odd to have an actual class called "MetaClass". The meta-object protocols with which I am familiar have the concept of a metaclass (a class whose instances are themselves classes), and the class Class is such a metaclass, but where does a class named MetaClass fit in? I discussed with Larry at the hackathon about the role that Class played in the metamodel. We decided that is was but a thin veneer between the meta-land and the user-land. I assume this is still the case. 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. As for how this differs from the other MOPs out there. I took the basic design of MetaClass, Class, Object from Smalltalk -80 actually, but modified the relationships a little to be more has-a the is-a. Let me expand/digress on this slightly .. The basic Smalltalk-80 idea of every user-level Class having an associated meta-level Class is still retained. However in Smalltalk, Class is an instance of MetaClass, where in the metamodel Class has-a instance of MetaClass. And as I said, Class is really nothing special, it but a level of indirection between the instance and MetaClass instance. I also borrowed many ideas from CLOS (in particular from book "The Art of the MetaObject Protocol"). CLOS is more like what you describe, where standard-class is the metaobject to define classes. I see this as mapping to the MetaClass, and our Class as being something akin to the find-class generic function in CLOS. If all metaclasses are instances of MetaClass, then MetaClass must be an instance of itself - is this then the only cycle in the graph? Yes, that is the cycle. 1) MetaClass is a subclass of Object 2) MetaClass is an instance of MetaClass OK. So the following code should be true (given a random instance $obj). $obj.meta.isa(MetaClass); $obj.meta.isa(Object); What does $obj.meta return - is it just a shortcut for $obj.class.class, or is something else going on here? Well, I did not see $obj.class speced in A/S12 so I never did anything with that. However the p6opaque instance structure I use in the prototype metamodel has a pointer back to the class object (see the 10,000 ft view again). So it is simple to implement it if we want too. But to answer your question, I was always under the impression that $obj.meta returned the MetaClass instance associated with the class that $obj is an instance of. However, keep in mind, these are somewhat fuzzy areas in Syn/Apoc12, and all details about $obj.meta only deal with "Introspection". Arghhh, these be uncharted waters 'mah Boy! If the former, then all of these should be true. $obj.isa(Object) yup, this will always be true. $obj.class.isa(Object) $obj.class.isa(Class) Again, no .class that I know of, however if there is, then these too should be true. $obj.meta.isa(Object) $obj.meta.isa(Class) $obj.meta.isa(MetaClass) I will agree with 1 and 3, but not with 2. I see Class and MetaClass are seperate things, at least how I coded it. However this, should be true (assuming we introduce a .class method): $obj.meta.class.isa(Class) However this is not a closed issue, so we can discuss it if you see a real need for things to be this way. However, Syn/Apoc 12 shows that the following is true if $foo is an instance of the Foo class. $foo.meta.isa(Foo) Hm. That doesn't make sense to me at all. Clearly I need to reread the Syn/Apoc. I'd expect $foo.isa(Foo) and that's it, although if nothing fancy with composition is going on $foo.
