TSa wrote:
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
WHAT types.

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 
one.

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.

But this
has got the drawback that there can be unwanted accidental equalities
that otherwise would indicate an error.
<snip>
Opinions?

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 "nonroot type".

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 you say:

  enum Foo ...

... then each value of that has a .WHAT of Foo.

-- Darren Duncan

Reply via email to