Darren Duncan wrote:
> These generally look like good changes, but I have a few points on which I'd
> like clarification or to make suggestions.
>> +Perl supports generic types through what are called "roles"
>> +which represent capabilities or interfaces. These roles
>> +are generally not used directly as object types. For instance
>> +all the numeric types perform the C<Numeric> role, and all
>> +string types perform the C<Stringy> role, but there's no
>> +such thing as a "Numeric" object. Common roles include:
>> + Stringy
> Please clarify; does "Stringy" mean a dense homogeneous sequence of
> primitives in general, meaning that both strings of characters and strings
> of integers are covered (as with a Perl 5 string) or does it just mean
It's a role, which means to me that it's form over function; interface
rather than implementation. As such, I'd expect to make Stringy
things that are built out of stuff other than characters. If need be,
consider making it a parametric role, with a type that defaults to
> Therefore I recommend that you add Blob to the list of types that does
> Stringy. In general, a Blob would be a string of bits but it could also be
> used as a string of bytes etc when its length in bits is an appropriate
> multiple of 8 say.
> Stringy operations like the "~" infix should work on Blob too as those
> aren't specific to characters. (For that matter, maybe infix "~" should
> also work on arrays or other Positional-doers to mean list-stitching, eg
> "$ary3 = $ary1 ~ $ary2", unless you have another better way to do that or it
> would confuse people.) Likewise, an analogy to substr() should work on
I'd rather keep infix:<~> out of Positional, as you can already do
that using infix:<,>. But I agree about the Blob.
>> + Numeric
>> + Real
>> + Integral
>> + Callable
>> + Positional
>> + Associative
>> +C<Rat> and C<Num> both do the C<Real> role.
> You should add C<Int> to this list of things that do C<Real>.
No; you should note that C<Integral> does C<Real>. Likewise, you
should note that C<Real> does C<Numeric>.
>> + Str Perl string (finite sequence of Unicode characters)
>> Bit Perl single bit (allows traits, aliasing, undef, etc.)
>> Int Perl integer (allows Inf/NaN, arbitrary precision, etc.)
>> + Num Perl number (approximate Real)
>> + Rat Perl rational (exact Real)
>> Complex Perl complex number
> So, now that we have the Numeric role (or the Real role) to be a catch-all
> label for things that are numeric, does this mean that the Num type now
> consists specifically of approximate real numbers, conceptually meaning that
> all Num are floating-point now, rather than Num being "Rat plus extra" as it
> seemed before?
> I think it would be useful for Num to be specifically float semantics all
> the time, just as Rat is the opposite, as this would help with some
> And users who don't care what they get can now use Real in their routine
> signatures etc rather than Num as the catch-all for real numbers.
As well, both Num and Complex should be Numeric, solving the
long-standing dilemma concerning Real and Complex numbers in Perl.
You might also want to note Ordered (or whatever it's called) as a
common role in Perl; Real does Ordered, but Numeric and Complex do
> On a tangent, I suggest renaming S32/Str.pod to S32/Stringy.pod as we now
> have a name of what Str and Buf both are (and Blob could go in there too).
> On another tangent, since I'm not sure that Blob literals have been defined
> in Perl 6 yet, I suggest something that combines aspects of numeric and
> character string literals, meaning a radix prefix plus string quotes; for
So what about custom delimiters?
>> -As with C<Hash> types, C<Pair> and C<Mapping> are mutable in their
>> +As with C<Hash> types, C<Pair> and C<PairSet> are mutable in their
>> values but not in their keys. (A key can be a reference to a mutable
>> object, but cannot change its C<.WHICH> identity. In contrast,
>> the value may be rebound to a different object, just as a hash
>> element may.)
> So given that PairSet is mutable as a whole (while PairValSet is immutable),
> can you please clarify the difference between PairSet and Hash, both of
> which have immutable keys and mutable values?
Back when it was Mapping, I was under the impression that the
difference involved whether or not the component Pairs were ordered -
that is, a Mapping was Positional as well as Associative. I could be
Jonathan "Dataweaver" Lang