Darren Duncan wrote:
Strong typing in Perl means that Perl is conveniently and reliably
keeping track of this user-intended interpretation of the data, so it
is easy for any piece of code to act on it in a reasonable way.
Strong typing lets user code be clean and understandable as it doesn't
have to do a lot of manual book keeping or error checking that Perl
can do for it, such as detecting the error of passing a character
string to a numeric multiplication operator.
First I have a question to the example of the behavior of a string
in a multiplication. Perl 6 automatically attempts a numerification.
But does that result in a failure for 'foo' or does that return 0?
That is, '3' * 3 == 9 is well formed and 'foo' * 3 is malformed, right?
I would expect for both examples to fail, unless '*' is expressly defined to
numify its arguments like '==' does, and in that case I would like to know how
to get the strict version of '*' that does fail so Perl can do more of my error
checking for me.
The fact that the first argument is a Str should mean that the programmer
expected for the argument to be a general character string (or if they actually
meant it to be a number, then Perl should tell them so they can go correct their
mistake where they made it a Str); just because it happens to now hold a string
that would cleanly coerce to a number doesn't matter; in the general case we
don't know that. Str.does(Num) is false since not every Str value has a
corresponding Num value.
What would be best, I think, is if '*' was defined to be strict to require
number arguments, and if people wanted the coercion, they would do it explicitly
with the nicely terse '+' prefix (spelling?); eg "+$mystr * 3 == 9".
This convenient and reliable book keeping to me means that there
are points in the execution sequence where type constraints are
checked. E.g. the constraint of a container is checked in an assignment.
But this must be seen as very different to the implementation types
of objects returned by WHAT. E.g. Bool, Bit, UInt and int8 are not
I agree with the last 3, but Bool definitely *should* be a distinct .WHAT type.
One approach to enums is that their WHAT is simply Int.
As applied to all enums in general, that is a *bad* idea, for more reason than
As one point, saying all enums are Int looks very much like a design smell,
taking what has commonly been the way for types defined as enums in C-land and
some places, and making it front and center in the user space where it should
never generally be seen.
has got the drawback that there can be unwanted accidental equalities
that otherwise would indicate an error.
And there as you've illustrated is one primary reason that all-enums-are-Int is
a bad idea.
Before I go further, I think for helping context to conceive that every data
type (which consists of a set of values) falls into exactly one of 2 disjoint
categories, depending on how they are defined, which I will call "root type" and
A root type is one that introduces new values into the type system, and the
.WHAT of every value would name a root type; examples of root types are Perl's
built-in primitive and collection types as well as all types declared using
'class' (and are defined in terms of named attributes).
A nonroot type is one that simply reuses existing values in the type system, and
no value would cite one of those as its .WHAT; examples of nonroot types are
those declared using 'subtype' and type unions like "Cat|Dog".
I'm not aware of any Perl 6 types that both introduce new values into the type
system and reuse existing ones also, but correct me if I'm wrong.
So with that context, I've observed that there seems to be at least 2 distinct
meanings that people use for what an enumerated type is. Some people would say
an enum introduces new values into the type system (and so is a root type), and
others would say an enum reuses existing values (and so is a nonroot type).
Looking at the "Enum" section of Synopsis 12, I'm not quite sure how that is
meant to be interpreted. Reading it literally suggests that Perl 6 takes the
nonroot approach with enums, saying for example that a Bool is a subtype of
integer. On the other hand, it could be saying that the 'enum' syntax is just
shorthand for a 'class' declaration with an attribute that is an integer and a
function named for each value.
I certainly hope that Perl 6 'enum' actually behave like a root type, and when
enum Foo ...
... then each value of that has a .WHAT of Foo.
-- Darren Duncan