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
> characters?

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

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
> predictability.
> 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
> example:
>  0b'1100100101'
>  0o'57013'
>  :2'1100100101'
>  :8'57013'
>  :16'DEADBEEF'

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

Reply via email to