how typish are roles
HaloO, from the recent threads 'class interface of roles', 'set operations for roles' and 'signature subtyping and role merging' I wonder how typish roles actually are. Some seem to consider roles as lightweight particles that serve to compose classes. I see them as the heavyweights in the type department. Doing a role is like a contract about certain functionality. So, what does @Larry think? I know that S12 states "The type system of Perl consists of roles, classes, and subtypes" but I don't have a clear picture of the inner workings or the formal model of this type system. E.g. what actually constitutes a type? How are the classes related to types? There is this fuzzy concept that a class is also a role of the same name as far as typing is concerned. How is the subtyping relation defined? Regards, TSa. --
Re: how typish are roles
In a message dated Wed, 25 Oct 2006, TSa writes: from the recent threads 'class interface of roles', 'set operations for roles' and 'signature subtyping and role merging' I wonder how typish roles actually are. Some seem to consider roles as lightweight particles that serve to compose classes. I see them as the heavyweights in the type department. Doing a role is like a contract about certain functionality. So, what does @Larry think? I'll let @Larry speak for @Larry, but at one point I was told that when C or C appear in signatures, those are roles, not classes; if you examined a particular Array or Hash, the class would be some implementation of the Array or Hash role, perhaps something like C or C or so on. So I'd tend to agree that roles "are the heavyweights in the type department." I've spent a few minutes with no luck trying to draw the actual discussion out of the #perl6 logger, but I'm pretty sure this was the gist. My (probably lame) interpretation of the Weltanschauung of Perl's typing is that roles, classes, type parameters, and type sets (junctive types, subsets, and mixtures thereof) are all equally relevant to the type system, and are all equally "typish" (though perhaps some are more primitive and some are more sugary). Unless you're actually composing or inheriting from something, you shouldn't care whether its type derives from a role, a class, a type set, or a type parameter. (And if you are composing or inheriting from it, you're not so much interested in its typishness as its behavior. Your new type will be/do whatever type(s) it inherited/composed, and will also be/do itself; beyond that, you shouldn't care) My gut feeling is that in real-world Perl 6 code we'll see a lot of both classes and roles being used as types. Roles will be more common typing particles when interacting with the Perl core or parts of other large code bases, and when you desire type safety. Classes will be more common when you just have a local need to have something to instantiate, or you want SMD or MMD. When programming in the large, the benefits of having a role will often be clearer; when programming in the small, a class will often (C not always ;) be more expeditious. I think the question (which you didn't directly raise, but I've heard from others) of whether "role" or "class" will have primacy is kind of as pointless as asking whether "subroutines" or "code blocks" have primacy: you can't use the former without the latter; the former is a useful abstraction for the latter, especially when code gets larger or is meant for sharing; and while each have places where they're more appropriate, either can be used in place of the other given a bit of syntactic twiddling. I know that S12 states "The type system of Perl consists of roles, classes, and subtypes" but I don't have a clear picture of the inner workings or the formal model of this type system. E.g. what actually constitutes a type? How are the classes related to types? There is this fuzzy concept that a class is also a role of the same name as far as typing is concerned. How is the subtyping relation defined? I can read S12 as saying that classes always do an eponymous role, and so role is what typing is "really" based on. Or alternatively, since when a role is used as if it were a class, it constructs an anonymous class that composes it, that class is what typing is "really" based on. But I don't see that it matters one way or the other; they seem functionally equivalent to me--as would having type based on C subsets, or having all these things participate equally, or any other angle you might want to look at it from. The behavior seems pretty ecumenical to me. In other words, I agree that it's fuzzy, but I personally read the fuziness as intentional, so as to allow implementations flexibility and prevent bad dependencies on particular "inner workings" of the type system. Trey
Re: [perl #40544] [NEW] Test for DOS line endings in Parrot text files
Bob, Many thanks for your reply! That's exactly the subtlety I was interested in knowing. Regards, Paul
Re: how typish are roles
HaloO,
Trey Harris wrote:
In other words, I agree that it's fuzzy, but I personally read the
fuziness as intentional, so as to allow implementations flexibility and
prevent bad dependencies on particular "inner workings" of the type system.
Thanks for the support. I figured that I've asked the same question more
than a year ago. I want to summarize what we have so far.
1) In type constraint position we can say things like A|B to effectively
mean a supertype of A and B by virtue of $_ ~~ A || $_ ~~ B.
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
3) The junctive ops |, & and ^ can be used in where clauses to form
type constraints. How does that apply to any(), all(), one() and
none()? Are they allowed as well? With none() we effectively get
type complement.
4) The junctive ops and the set operators (|) and (&) are *not* yet
available as type constructors in role definitions, that is things
like 'role does A(&)B'. To comply with 2) this should create an
intersection type even though it joins the interfaces of A and B.
Does recursive use of roles in their own definition produce F-bounds?
role A does Gen[A] {...}
or perhaps
role A where A.does(Gen[A]) {...}
Regards, TSa.
--
[perl #40596] [CAGE] modify perl coding standard test format
# New Ticket Created by Jerry Gay # Please include the string: [perl #40596] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40596 > modify perl coding standard test format to match the c tests--one test per standard, rather than one test per file. coding standard tests are designed to test maintainability, not functionality. testing parrot functionality is much more important than testing maintainability--just look at perl 5 :-) inflating test numbers (and percentages) by adding a zillion coding standards tests leads to false perception of test coverage. i'd like very much to avoid this situation. ~jerry
Re: [perl #40593] [CAGE] make t/codingstd/linelength.t output look like other coding standard tests
On 10/24/06, Will Coleda <[EMAIL PROTECTED]> wrote: Not all tests follow the "one test reporting on many files" paradigm: see t/codingstd/perlcritic.t FWIW,in general, I prefer the perlcritic method. as i just wrote in a new ticket for perl coding standard test reformatting... coding standard tests are designed to test maintainability, not functionality. testing parrot functionality is much more important than testing maintainability--just look at perl 5 :-) inflating test numbers (and percentages) by adding a zillion coding standards tests leads to false perception of test coverage. i'd like very much to avoid this situation. therefore, we're going with one test per standard, rather than one test per standard per file. ~jerry
Re: [perl #40596] [CAGE] modify perl coding standard test format
On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote: modify perl coding standard test format to match the c tests--one test per standard, rather than one test per file. coding standard tests are designed to test maintainability, not functionality. testing parrot functionality is much more important than testing maintainability--just look at perl 5 :-) inflating test numbers (and percentages) by adding a zillion coding standards tests leads to false perception of test coverage. i'd like very much to avoid this situation. ~jerry Jerry, I fully understand your reasoning, but this is going to slow down the tests. Perl::Critic's overhead comes primarily from parsing each source file, not from checking the standards, so Test::Perl::Critic is oriented to work per-file. Your suggested change goes across the grain for Perl::Critic. Certainly the perlcritic.t can be changed to have just one test -- all files pass all standards, or not -- without a performance penalty, but perhaps that might be too much in the other direction? Chris
Re: [perl #40596] [CAGE] modify perl coding standard test format
On 10/25/06, Chris Dolan <[EMAIL PROTECTED]> wrote: On Oct 25, 2006, at 1:24 PM, Jerry Gay (via RT) wrote: > modify perl coding standard test format to match the c tests--one test > per standard, rather than one test per file. > > coding standard tests are designed to test maintainability, not > functionality. testing parrot functionality is much more important > than testing maintainability--just look at perl 5 :-) > > inflating test numbers (and percentages) by adding a zillion coding > standards tests leads to false perception of test coverage. i'd like > very much to avoid this situation. > ~jerry Jerry, I fully understand your reasoning, but this is going to slow down the tests. Perl::Critic's overhead comes primarily from parsing each source file, not from checking the standards, so Test::Perl::Critic is oriented to work per-file. Your suggested change goes across the grain for Perl::Critic. Certainly the perlcritic.t can be changed to have just one test -- all files pass all standards, or not -- without a performance penalty, but perhaps that might be too much in the other direction? one overall test for perlcritic is fine with me. there's nothing stopping us from parsing perlcritic output if we want a different format, however i'd rather not go that far. additionally, i'd like to see less verbose output from perlcritic. the thousands of lines of diag output from a single test file is ...distracting. i'm sure it's configurable, but i haven't taken the time to look into it. do you have any quick suggestions, or should i dive into the docs? ~jerry
Re: [perl #40596] [CAGE] modify perl coding standard test format
On Oct 25, 2006, at 3:23 PM, jerry gay wrote: one overall test for perlcritic is fine with me. there's nothing stopping us from parsing perlcritic output if we want a different format, however i'd rather not go that far. additionally, i'd like to see less verbose output from perlcritic. the thousands of lines of diag output from a single test file is ...distracting. i'm sure it's configurable, but i haven't taken the time to look into it. do you have any quick suggestions, or should i dive into the docs? ~jerry Jerry: * open t/codingstd/perlcritic.t * search for "-format" * look at the below URL for the allowed sprintf-like codes http://search.cpan.org/~thaljef/Perl-Critic-0.2/lib/Perl/Critic/ Violation.pm#OVERLOADS The current format is: -format => '[%p] %m at %l,%c', which yields "[TestingAndDebugging::RequireUseStrict] Code before strictures are enabled at 235,1" If you want to see fewer errors, add -top => 5 after the -format to only show the first 5 violations per .pm file. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: [HOWTO] add a C file to get archived in libparrot.a
Adding the file to the INTERP_O_FILES section in config/gen/makefiles/root.in and re-running Configure should do the trick. --AT On 10/24/06, Karl Forner <[EMAIL PROTECTED]> wrote: On 10/23/06, Jonathan Worthington <[EMAIL PROTECTED]> wrote: > > Karl Forner wrote: > > I've added one C src file, say src/foo.c, and include/parrot/foo.h, and > a > > test in t/src/foo.t. > > I've changed the MANIFEST file accordingly, but I can not manage to > > have my > > foo.o file to be added in libparrot.a (after a make clean;perl > > Configure.pl > > ;make) > > > > What did I miss ? > Not sure if you've solved this yet, but just a guess: did you try a > "make realclean"? Yes, but that does not change anything. My file does not appear in the Makefile (except for foo.h). I have absolutely no clue of the process used to generate the list of C files to be linked into the parrot interpreter.
[svn:parrot-pdd] r15024 - trunk/docs/pdds/clip
Author: jonathan Date: Wed Oct 25 15:29:31 2006 New Revision: 15024 Modified: trunk/docs/pdds/clip/pdd15_objects.pod Log: Add REQUIREMENTS section to PDD15 Objects, to enable us to start fleshing out what Parrot's object system needs to do. Includes hopefully most of what Perl 6 and .Net need as a starting point. Modified: trunk/docs/pdds/clip/pdd15_objects.pod == --- trunk/docs/pdds/clip/pdd15_objects.pod (original) +++ trunk/docs/pdds/clip/pdd15_objects.pod Wed Oct 25 15:29:31 2006 @@ -5,6 +5,99 @@ docs/pdds/pdd15_objects.pod - Object and Class semantics for Parrot +=head1 REQUIREMENTS +This PDD is due an overhaul. This requirements section is for language +implementers to list the OO-related needs of their language in so as to aid +that. + +=head2 Classes +A class is a collection of methods and attributes. It would be desirable, for +those classes whose definition is fully known at compile time, to have a +convenient way to have the class along with its attributes and methods stored +into a PBC file rather than created at runtime. However, creation of new +classes at runtime will be needed too. + +=head2 Attributes +Attributes are instance data associated with a class (or role, however those +are supported). They may not always be of a type specified by a PMC, though +boxing/unboxing is of course an option. + +Perl 6: All attributes are opaque (not externally visible, even to any +subclasses). + +.Net: Attributes may be private (not externally visible), public (always +externally visible), protected (only visible to subclasses) and internal +(only visible inside the current assembly - the closest correspondnece in +Parrot is perhaps only visible inside the same PBC file). Additionally, it +is allowable for a subclass to introduce an attribute of the same name as +the a parent class has, and they both exist depending on what type an +instance of the class is currently viewed as being (read: there is a +difference between the type of the reference and the type of the value). + +=head2 Methods +Perl 6: Methods may be public (anyone can invoke them) or private (only +invokable by the class they are defined in). Additionally, submethods are +methods that do not get inherited. + +.Net: Like attributes, methods may be public, private, protected or internal. + +=head2 Inheritance +Perl 6: Multiple inheritance. + +.Net: Single inheritance. + +=head2 Interfaces +An interface specifies a set of methods that must be implemented by a class +that inherits (or implements) the interface, but does not provide any form of +implementation for them. + +.Net: Interfaces are pretty much what was just describe above. XXX Need to +check behaviour of you implement two interfaces with methods of the same name. + +=head2 Roles +A role consists of a set of methods and attributes. It cannot be instantiated +on its own, but must be composed into a class. When this happens its methods +and attributes become of that classes methods and attributes. This may happen +at compile time or runtime, however when a role is composed into a class at +runtime then what really happens is that a new anonymous class is created with +the role composed into it and then the namespace entry for the existing class is +updated to refer to the new one. Note that this means classes must be garbage +collectable, with all those referred to by a namespace or with objects of that +class existing being marked live. + +Perl 6: Roles pretty much are a Perl 6 thing, so the definition above contains +all that is needed. An open question is whether Parrot worry about collision +detection? For compile time composition that's easy to punt to the compiler; +for runtime composition, that's not so easy though. + +=head2 Introspection (aka Reflection) +Perl 6: Reflection provides access to a list of methods that a class has, its +parent classes and the roles it does, as well as the name of the class and its +memory address. For methods, their name, signature, return type and whether +the method is declared multi are available. + +.Net: Reflection provides access to a list of attributes and methods as well as +the name of the class and its parent. The types of attributes and signatures of +methods are also available. + +=head2 Inner Classes +An inner class is essentially a class defined within a class. Therefore it has +access to things private to its outer class. + +Perl 6: Inner classes are allowed, and may also be private. + +.Net: Inner classes are allowed and may be private, public, protected or +internal. + +=head2 Delegation +Delegation is where a method call is "forwarded" to another class. Parrot may +provide support for simple cases of it directly, or could just provide a "no +method matched" fallback method that the compiler fills out to implement the +delegation. + +Perl 6: Delegation support is highly flexible, even allowing a regex to match +method names that sh
Re: OO Requirements [was Re: classnames and HLL namespaces -- help!]
Allison Randal wrote: More specifically: If you have any questions related to a PDD in clip, please add them to a QUESTIONS section at the end of the PDD. For requirements, use REQUIREMENTS. Neither of these sections will live in the final version of the PDD, so it's a flag for me to process the discussion. (And it's enormously easier to roll the discussion into the PDD when it's collected together like that than scattered across several months of email. Especially considering how terrible Thunderbird's full-text searching is.) OK, so I've added a REQUIREMENTS section to the objects PDD now and filled it out with some (hopefully most) of what Perl 6 and .Net need as a start. I know I've missed some things, and I'll bet my Perl 6 requirements are somewhat lacking in the details - if you object to anything I wrote, commits and patches to fix it would be great. :-) What would be *really* great, though, is if implementers of other languages that do OO stuff could contribute their needs to this section. If you would rather send a patch than ci (or don't hve a commit bit), just send it along to the list and I'll make sure it's applied. Thanks! Jonathan
[perl #40443] Separate vtable functions from methods (using :vtable)
On Sun Oct 01 16:22:10 2006, mdiep wrote:
> At the OSCON 2006 Hackathon, it was decided that we should separate
> vtables from methods and add a new :vtable label for PIR subs to mark
> them as vtable functions. This gets rid of the current namespace
> pollution caused by vtables and allows us to abandon the leading
> underscores for PIR vtable functions.
>
> .sub get_string :vtable
> .return("end namespace pollution!")
> .end
>
Just to check, that this is still meant to happen? Anyone feel it should
be put off until the objects/namespaces stuff is sorted out, or shall I
just dive right in?
Thanks,
Jonathan
Re: [perl #40443] Separate vtable functions from methods (using :vtable)
On Wednesday 25 October 2006 16:38, [EMAIL PROTECTED] via RT wrote: > Just to check, that this is still meant to happen? Unless Allison objects, it seems like the cleanest way to support overloading semantics from various languages (Perl 5: FETCH, Python: __some_really_ugly_method_name__) without actually making namespace collisions. > Anyone feel it should be put off until the objects/namespaces stuff is > sorted out, or shall I just dive right in? As long as the interface works (and it seems sensible to me), we can fix the implementation in plenty of ways. -- c
Re: how typish are roles
TSa wrote:
I want to summarize what we have so far.
1) In type constraint position we can say things like A|B to effectively
mean a supertype of A and B by virtue of $_ ~~ A || $_ ~~ B.
Right. This would be equivalent to "Any where {.does(A) or .does(B)}".
2) We have A&B and the A B juxtaposition to mean $_ ~~ A && $_ ~~ B
which is an intersection (sub)type of A and B.
Not according to my reading of S06: if you want to force a parameter
to match both of two different roles, you must use a where clause.
3) The junctive ops |, & and ^ can be used in where clauses to form
type constraints. How does that apply to any(), all(), one() and
none()? Are they allowed as well? With none() we effectively get
type complement.
AFAICT, any() can be used (almost) anywhere that infix:<|> can be;
ditto with the other junctive ops and their associated functions. In
particular, I see no reason why they would be forbidden in where
clauses. (The one case where "any" might not be usable as a
substitute for infix:<|> is point 1, above. Even then, I'm not really
certain that it can't be used.)
4) The junctive ops and the set operators (|) and (&) are *not* yet
available as type constructors in role definitions, that is things
like 'role does A(&)B'.
Correct. If there's a queue being maintained for post 6.0 features,
I'm hoping that it's in the queue; but it isn't going to be a 6.0
feature AFAIK.
Does recursive use of roles in their own definition produce F-bounds?
role A does Gen[A] {...}
I don't see why not. Heck, while it would usually be silly to do so,
I could even see cyclic role definitions working:
role A does B { ... }
role B does A { ... }
or even
role A does A { ... }
(though why any role would ever want to compose itself is beyond me.)
--
Jonathan "Dataweaver" Lang
Re: OO Requirements [was Re: classnames and HLL namespaces -- help!]
Jonathan Worthington wrote: OK, so I've added a REQUIREMENTS section to the objects PDD now and filled it out with some (hopefully most) of what Perl 6 and .Net need as a start. Thanks Jonathan, it's a great start! Allison
Re: [perl #40443] Separate vtable functions from methods (using :vtable)
[EMAIL PROTECTED] via RT wrote:
On Sun Oct 01 16:22:10 2006, mdiep wrote:
At the OSCON 2006 Hackathon, it was decided that we should separate
vtables from methods and add a new :vtable label for PIR subs to mark
them as vtable functions. This gets rid of the current namespace
pollution caused by vtables and allows us to abandon the leading
underscores for PIR vtable functions.
.sub get_string :vtable
.return("end namespace pollution!")
.end
Just to check, that this is still meant to happen? Anyone feel it should
be put off until the objects/namespaces stuff is sorted out, or shall I
just dive right in?
This is the main thing Chip and I talked about in our last face-to-face
meeting. We came up with 3 basic parameters: whether a method is a
vtable method, whether it has a vtable name distinct from the method
name, and whether it has a method name at all (or is anonymous, i.e.
only a vtable method). The interface I scrawled out over coffee is:
# method name is the same as vtable name
.sub get_string :method :vtable
# accessible as either $obj.stringify() or vtable
.sub stringify :method :vtable('get_string')
# accessible only as vtable
.sub get_string :method :anon :vtable
.sub stringify :method :anon :vtable('get_string')
Which reuses the existing concept of:
# method has an entry in the namespace
.sub stringify :method
# method has no entry in the namespace
.sub stringify :method :anon
(There's not much point in using the 4th option where you specify a name
for the method, make it anonymous, and then specify a separate name for
the vtable entry, but we'll support it for the sake of orthogonality.)
The reasoning for making :vtable additive rather than exclusive with
:method is that it's common to want to add behavior that's both a method
on the object and a vtable entry.
As a side effect of this solution, the leading double underscore goes
away for vtable names. So it's now just 'init' instead of '__init',
'get_bool' instead of '__get_bool', etc. The underscores were just a
hack to alleviate namespace pollution anyway.
Even though "pure" vtable methods aren't stored in the addressable part
of the namespace, we came to the conclusion that they should be attached
to the namespace, because an anonymous class can be associated with a
namespace at runtime, and when it is, it should get not only the methods
of that namespace, but also the overloaded vtable entries.
(I can see an argument of brevity for an alternate solution where the
3rd and 4th options have only :vtable and not :method and :anon:
# accessible only as vtable
.sub get_string :vtable
.sub stringify :vtable('get_string')
but I don't like the fact that this would make :vtable mean different
things in different contexts. Together with :method, :vtable would mean
"also make an entry in the vtable overload list for this namespace", but
without :method it would mean "don't make an entry for this subroutine
in the namespace, and treat this subroutine as a method, and make an
entry in the vtable list". I prefer to keep each of those separated into
their own adverbs, especially since we already have the adverbs.)
Allison
