Table of Perl 6 "Types"
Stevan Little
I hope everyone is having a good start to the new year.
As Audrey's posts have mentioned, we are starting to work on
container and boxed types in the PIL^N/PIL2 runcore. Over the
holidays I went through the most recent Synopsis and attempted to
compile a list of what I think are the core Perl 6 "types" based on
what was mentioned in the various Synopsis.
I say "types" because I want not to get into a discussion on type
theory/lattices/etc. or anything of the sort right now. I want only
to try to grok the hierarchy of types so that I can begin to build
the container and boxed types in PIL^N.
Now the closest thing to a full list I found was in S06, but it
seemed to leave out some things mentioned in the other (possibly out
of date) Synopsis, so I built the table below.
In addition to just listing them, I also attempted to (loosly)
structure them into a hierarchy to illustrate the (sub|super)-type
relationships. The table is split into 3 columns, the first the type
(tab depth determining place in the heirarchy), the second is the
Synopsis it was mentioned in (a blank value in this column means it
was in the S06 list), and lastly a description of the type (if it's
meaning not obvious that is).
I am sure I am probably missing a few, have mistakenly put others in
the wrong place in the heirarchy, and/or I may even be completely and
totally in the wrong in every way. But I figured it was a start, and
I would see what others had to say.
Thanks,
Stevan
------------------------------------------------------------------------
-------
Any : : The "top" type
------------------------------------------------------------------------
-------
Bit : : Basic Bit type
Bool : : Boolean type (probably built
on Bit)
------------------------------------------------------------------------
-------
Num : : Base Numeric type
Int : :
Float : :
Complex : :
------------------------------------------------------------------------
-------
Byte : S29 : straddles Numeric and
Character types
Char : S29 : Base Character type
LanguageChar : S29 :
Grapheme : S29 :
CodePoint : S29 :
------------------------------------------------------------------------
-------
Str : :
------------------------------------------------------------------------
-------
Ref : :
Array : :
Hash : :
Pair : :
Range : :
StrRange : :
NumRange : :
Proxy : :
------------------------------------------------------------------------
-------
IO : :
------------------------------------------------------------------------
-------
Code : : Base for all executable objects
Block : : Base for all embedded
executable object
Routine : : Base for all nameable
executable object
Sub : :
Macro : :
Method : :
Submethod : :
MultiSub : :
Multimethod : :
Lvalue : S06 :
------------------------------------------------------------------------
-------
Grammar : S05 : likely derived from Module
Rule : S05 : likely derived from Method
Token : S05 :
------------------------------------------------------------------------
-------
Object : :
Package : :
Module : :
Class : :
Role : :
------------------------------------------------------------------------
-------
List : : Lazy Perl list
ParamList : :
Named : S06 : A named param (derived from
Pair)
Tuple : : Completely evaluated
(immutable) list
------------------------------------------------------------------------
-------
Stevan Little
Chip pointed out to me that my post was severely mangaled because it
was too wide, so I have reformatted to fit within 70 columns, hope
this works better.
NOTE: I realize that this format may be entirely inappropriate for
this too. The type "hierarchy" is likely to be more graph-ish
especially when we start to introduce Roles as well as Classes into
the mix. But this is a starting point at least.
Thanks,
Stevan
---------------------------------------------------------------------
Any : : The "top" type
---------------------------------------------------------------------
Bit : : Basic Bit type
Bool : : Boolean type (probably built on Bit)
---------------------------------------------------------------------
Num : : Base Numeric type
Int : :
Float : :
Complex : :
---------------------------------------------------------------------
Byte : S29 : straddles Numeric and Character types
Char : S29 : Base Character type
LanguageChar : S29 :
Grapheme : S29 :
CodePoint : S29 :
---------------------------------------------------------------------
Str : :
---------------------------------------------------------------------
Ref : :
Array : :
Hash : :
Pair : :
Range : :
StrRange : :
NumRange : :
Proxy : :
---------------------------------------------------------------------
IO : :
---------------------------------------------------------------------
Code : : Base for all executable objects
Block : : Base for all embedded executable object
Routine : : Base for all nameable executable object
Sub : :
Macro : :
Method : :
Submethod : :
MultiSub : :
Multimethod : :
Lvalue : S06 :
---------------------------------------------------------------------
Grammar : S05 : likely derived from Module
Rule : S05 : likely derived from Method
Token : S05 :
---------------------------------------------------------------------
Object : :
Package : :
Module : :
Class : :
Role : :
---------------------------------------------------------------------
List : : Lazy Perl list
ParamList : :
Named : S06 : A named param (derived from Pair)
Tuple : : Completely evaluated (immutable) list
---------------------------------------------------------------------
> ---------
> Ref : :
> Array : :
> Hash : :
> Pair : :
> Range : :
> StrRange : :
> NumRange : :
> Proxy : :
> ----------------------------------------------------------------------
> ---------
> IO : :
> ----------------------------------------------------------------------
> ---------
Larry Wall
: Hello again,
:
: Chip pointed out to me that my post was severely mangaled because it
: was too wide, so I have reformatted to fit within 70 columns, hope
: this works better.
:
: NOTE: I realize that this format may be entirely inappropriate for
: this too. The type "hierarchy" is likely to be more graph-ish
: especially when we start to introduce Roles as well as Classes into
: the mix. But this is a starting point at least.
Indeed, it's rather counterintuitive, but the basic types will probably
stress our type system more than the complicated ones. The problem
with using a word like "hierarchy" is that implies only one kind of
relationship, and in the context of OO, a particularly Liskovian one.
I will assume the hierarchy below is intended as strictly "isa". We
may need to differentiate role names from class names in some cases,
though it would be nice if we could avoid multiplying entities.
Perhaps there's some way to be systematic about the relationship of
a role and its (presumably autogenerated) class when a role is complete
enough to be used as a class.
: ---------------------------------------------------------------------
: Any : : The "top" type
: ---------------------------------------------------------------------
: Bit : : Basic Bit type
: Bool : : Boolean type (probably built on Bit)
Note: almost every type "does" Bool, so if this were a role hierarchy
they'd all be listed under here. Similarly for Nums that "do" Str and
Strs that "do" Num. (Though I'd point out that Perl 5 doesn't
privilege one of those types as the main one. A scalar just does
all of those, which makes me wonder if we're missing an Item type
that doesn't commit to a specific scalar type.)
: ---------------------------------------------------------------------
: Num : : Base Numeric type
: Int : :
: Float : :
: Complex : :
This bothers me. The reason we put in Num in the first place was to
get rid of things like Float and Double. Every time I see "Float"
or "Double" in a Perl 6 program I will feel like a failure.
"Complex" doesn't bother me nearly so much, but the issue is also there.
I guess the question boils down to what gets returned when you ask for
the type of sqrt(-1). Are all Nums implicitly Complex if necessary?
Are Nums implicitly Int when the fractional part is provably 0?
The basic underlying issue here is to what extent our understanding
of native types should map over to the abstract types. Yes, we certainly
want to distinguish between "int" and "complex" native types. It's not
so clear that this implies we have to distinguish between Int and Complex
when it comes to choosing a storage representation. The Num type should
be managing that for us.
On the other hand, we could certainly want to place an Int constraint
on a numeric storage location. But then we're starting to get into
constrained types rather than derived types, I suspect.
So another dimension to our typespace is the "intent" of the type name
in a particular context. We've run into this issue before. When we
declare a variable of type Int, do we mean that it must "do" Int or
it must "be" an Int?
: ---------------------------------------------------------------------
: Byte : S29 : straddles Numeric and Character types
: Char : S29 : Base Character type
: LanguageChar : S29 :
: Grapheme : S29 :
: CodePoint : S29 :
I don't see why you're breaking out Byte here. The other character
types could also have numeric interpretations, and in fact CodePoint
has a useful numeric interpretation. I think the basic Char type
implies the "maximum" char type in the current context, and in a
"use bytes" context Char means Byte, just as in the default context
Char means Grapheme.
(I also think we have to shorten these names for Huffmanly reason, unless
people will always just use Char to mean "current maximally abstract".)
I'm also not sure that you can have a naked LanguageChar except as
a role. By definition a LanguageChar knows what language it is,
so it'd have to be a FrenchChar or a JapaneseChar, or some such.
: ---------------------------------------------------------------------
: Str : :
Are strings typed like chars? And if so, what happens when you append
a Japanese character to a French string?
: ---------------------------------------------------------------------
: Ref : :
Still not sure I believe in Ref as a use-visible object type...
: Array : :
: Hash : :
: Pair : :
Arguably a Pair is a kind of constrained Hash...
: Range : :
: StrRange : :
: NumRange : :
Iterators? Maybe there's no such thing as a naked Iterator either...
: Proxy : :
I wonder if Proxy might be a special kind of Ref.
: ---------------------------------------------------------------------
: IO : :
No doubt there's lots of subtypes hiding in there...
: ---------------------------------------------------------------------
: Code : : Base for all executable objects
: Block : : Base for all embedded executable object
: Routine : : Base for all nameable executable object
: Sub : :
: Macro : :
: Method : :
: Submethod : :
: MultiSub : :
: Multimethod : :
: Lvalue : S06 :
Lvalue looks wrong there. "is rw" cuts across the other types, so it's
probably just a role.
: ---------------------------------------------------------------------
: Grammar : S05 : likely derived from Module
More like Class, I'd think.
: Rule : S05 : likely derived from Method
: Token : S05 :
I don't think @Larry ever finally settled the rule/token whitespace
issue, so that's probably still a bit conjectural. We were kind of
waiting to see what turned out to be most useful for the Perl 6 parser.
: ---------------------------------------------------------------------
: Object : :
: Package : :
: Module : :
: Class : :
: Role : :
I'm not sure Object belongs at the front of that list. It's not clear
whether Any/Object is a useful distinction except maybe as an expression
of intent to autobox to a type that can represent undef (or other less
violent forms of genericity).
: ---------------------------------------------------------------------
: List : : Lazy Perl list
: ParamList : :
: Named : S06 : A named param (derived from Pair)
: Tuple : : Completely evaluated (immutable) list
: ---------------------------------------------------------------------
Luke has expressed reservations about the Tuple/List distinction, but
I don't yet understand all the issues there.
Well, as you say, it's a good start. We'll just keep banging our heads
against the wall until we find the resonant frequency of either the
wall or our heads.
Larry
Dave Whipp
> : ---------------------------------------------------------------------
> : Num : : Base Numeric type
> : Int : :
> : Float : :
> : Complex : :
>
> This bothers me. The reason we put in Num in the first place was to
> get rid of things like Float and Double. Every time I see "Float"
> or "Double" in a Perl 6 program I will feel like a failure.
I'd suggest the the concepts of "Real" and "Int" are sufficiently
distinct to warrant types (The term "Float" is bad IMO because it
implies a specific style of implementation -- A Real could, in
principle, be implemented as a fixed-point value).
An Int is Enumerable: each value that is an Int has well defined succ
and pred values. Conversely, a Real does not -- and so arguably should
not support the ++ and -- operators. Amonst other differences, a
Range[Real] is an infinite set, whereas a Range[Int] has a finite
cardinality.
(perhaps this discussion belongs on p6l)
ava...@gmail.com
> An Int is Enumerable: each value that is an Int has well defined succ
> and pred values. Conversely, a Real does not -- and so arguably should
> not support the ++ and -- operators. Amonst other differences, a
> Range[Real] is an infinite set, whereas a Range[Int] has a finite
> cardinality.
++ and -- aren't meant to increment or decrement to the next/last value
in the set, they're increment or decrement by one (see perlop). I can
see your point about them not making sense for Real since it's not an
enumerable set like integers but I don't think it would be in the
spirit of DWIM to have to do:
my Int $i = 5;
say ++$i;
and
my Real $i = 5; # Or Num, Float or whatever
say $i += 1;
as that would be both inconsistent with Perl 5, C and every language
that has ++/-- as well as being internally inconsistent in Perl 6 to
have to use different constructs to increment by one for different
number types.
There's of course the argument that ++/-- aren't needed at all since
they're really just relics from C where you needed them for pretty much
every loop, although they're definitely usable almost everywhere where
loop(;;) is appropriate in Perl 6 you don't need them as much as C,
some other languages such as Python and Ruby don't have them at all,
but that's a bit offtopic;)
> (perhaps this discussion belongs on p6l)
It sure does;)