Beginning Notes for the Perl 6 Type Hierarchy

I stated in my last post some ideas I came up with involving Perl 6 that I’d be at least semi-interested in doing. Although the code repository (P6SSMPR) was actually my favorite idea, I decided to start with the small (and remotely possible) stuff, namely a project whose ultimate goal is a pretty graph.

For the past couple days I’ve been taking notes on any mention of types and especially the hierarchy of types in Perl 6. You can see the work so far here. S01 contained no information, while S02 is proving to be quite the ordeal (as seen in this recent commit message). I knew this wasn’t going to be easy.

I state the goals for this project in the README (by the way, yes I do support the use of .pod6 as a valid extension), but to repeat them here, I want to do this for two reasons:

  1. To help newcomers to Perl 6 understand the type system (one less confusing aspect of the language to be all alone on)
  2. To reveal any potential inconsistencies in the synopses, at least what’s pertinent to types and the type hierarchy.

There it is! Hope you’ll follow the work, and snicker at the occasional witty note/commit message.

(Actually, moritz mentioned that there is no type hierarchy. In that case, is the P6 Standard Objects Inheritance Chain? Or maybe SCOI. No wait, definitely CISO. No,…)

TL;DR: You just missed a valuable cash opportunity in the blog post. Maybe next time.

This entry was posted in Progress Happened and tagged , , , , , . Bookmark the permalink.

3 Responses to Beginning Notes for the Perl 6 Type Hierarchy

  1. raiph says:


    I’m neither jedi nor sith. I was (10 years ago!) an approximately “User level” (“Seven Stages of a Perl Programmer”) perl 5 coder and am a long time perl6 lurker.

    I’m confused about whether your “potential confusion” annotations are at least partly due to you being confused or merely your sense that others might be. I suspect it’s all or mostly the latter but for now I’m going to write as if you are/were somewhat confused yourself. If your annotations are indeed /purely/ about others being confused, please consider what I write to be simply a sample of whether another near beginner was/is confused, and perhaps a suggestion as to how things might be made clearer.

    As you’ll see, I’m confused about some things you aren’t annotating with “potential confusion”. So I’ve added my own “potential confusion” annotations where appropriate.

    I may not be able to follow this post up, at least not for weeks, but had the time and impulse today to post in the hope it’s helpful.


    > =head2 The P6Opaque Datatype
    > P6Opaque is a new fundamental datatype to support OO encapsulation. External access to opaque objects is always through method calls.
    > B Probably explained later on, but there should be a clearer explanation of it here (or a link to where in the spec it’s more detailed).

    I imagine all would agree with /eventual/ incorporation of (more) links. However, I imagine concerns about linkrot.

    “What does P6Opaque do?”

    To me it seems, er, clear. 😉

    To me “P6Opaque”, “support OO encapsulation”, and “External access to opaque objects is always through method calls” strongly suggest the “Smalltalk and Ruby” approach to “Information Hiding” written up in

    I imagine that the reason this type appears at the start is that all official perl6 types (behave as if they) are subtypes (for some definition of “behave” and “subtype”) of P6Opaque, unless otherwise stated. (I imagine there may be official close-to-the-metal (native?) perl6 types that aren’t P6Opaque subtypes.)

    > =head2 Container Types
    > A variable may be bound to a container type that specifies how the container works, without saying what kinds of things it contains.
    > B Although it’s not the spec’s job to do this, example code showing how one might use this would be extrememly helpful in explaining what a container type even I.

    Again, the description seems clear to me.

    Try s/container/shoebox/:

    A shoebox type specifies what happens when you put stuff in a shoebox of that type, take stuff out of it, look inside it, move it, etc. This can be independent of what goes in and out of the shoebox.

    Examples? Hmm. A particular shoebox (type) keeps a count of the number of times something gets put inside or taken out. Another shoebox moves itself to a different storage medium, or upgrades itself to become bigger, if it gets full. Another switches on a fire extinguisher (debugger or processor panic instruction) if it detects a fire (parity checking error).

    I imagine the type, er, anarchy (“it’s not a hierarchy”) includes two (almost?) entirely distinct areas, one for containers, the other for values. Hmm. Maybe junctions are weird too. And then there’s Mu etc. Hmm. Someone needs to write up… oh.

    > =head2 Containers of Native Types
    I> f you say C, you’re saying that the array, implemented by the MyArray class, contains native integers. Untyped arrays and hashes are still acceptable.

    B I’m pretty sure this comment is just meant to be a reassurance that one isn’t forced to specify a type for the values in an array. But maybe I’m wrong. Does “untyped” refer to the array/hash itself (which I thought had an implicit type, so that seems wrong) or the values it contains (seems likely)? Does “acceptable” mean you can assign an untyped array to a container of native types (makes no sense, but hey)?

    > =head2 Built-in Type Conventions
    > Built-in object types start with an uppercase letter. This includes both immutable types (e.g. “Int”, “Str”, “Regex”, “Block”) and mutable (container) types (e.g. “Scalar”, “Buf”, “Routine”, “Module”, and non-instantiable Roles such as “Callable”, “Failure”, and “Integral”).

    B I associate objects with instantiation. Hmm. I guess a Role could be a prototype Class like object like thing whose interface does not allow creation of a corresponding non-prototype object. Or something like that. 😉


    Argh. Gotta run. Hope this helped. I think I’ll be able to get online again tomorrow.

    love, raiph

  2. Pingback: Perl 6 and CPAN? Well… | Rakudo Death Star

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s