On Tue, Jan 03, 2006 at 07:34:41PM -0500, Stevan Little wrote: : 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
