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 characters. > 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 not. > 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' > 0x'DEADBEEF' > > :2'1100100101' > :8'57013' > :16'DEADBEEF' So what about custom delimiters? q:2<1100100101> q:8[57013] q:16~DEADBEEF~ >> -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 wrong. -- Jonathan "Dataweaver" Lang
