pugs-comm...@feather.perl6.nl wrote:
Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502

add Stringy role
attempt to distinguish numeric objects from Numeric, Real, Integral, etc roles
split Pair into immutable PairVal and mutable Pair
split Mapping into immutable PairValSet and mutable PairSet
general typological housekeeping that will doubtless gobsmack the implementors

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?

Now, because below you say that both the immutable Str and the mutable Buf do Stringy, that implies the former definition, that this isn't restricted 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.

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

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

     Bool        Perl boolean
+    PairVal     An immutable Pair
+    PairValSet  Set of PairVals with no duplicate keys

+These types do (at least) the following roles:
+    Class       Roles
+    =====       =====
+    Str         Stringy
+    Bit         Numeric Boolean
+    Int         Numeric Integral

Again, you should add Real explicitly as a role that Int does.

+    Num         Numeric Real
+    Rat         Numeric Real
+    Complex     Numeric
+    Bool        Boolean
+    Set         Associative[Bool]
+    Bag         Associative[UInt]
+    PairVal     Associative
+    PairValSet  Associative
+ Blob

Again, Stringy should be a role of Blob (as it is of Buf), if Stringy means what I think it does.

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:



Unlike numbers in general, the radixes would be restricted to a positive power of 2 because we're talking about binary bits, so eg no :5'' allowed.

Also, as with numbers, an underscore could be allowed in the middle of the string simply as a visual separator that doesn't affect the value.

To me, the string quotes says string rather than numeric (which don't use quotes), and the radix modifier at the front says bit string rather than character string (which don't use radixes).

Unless that conflicts with something, please give it some consideration.

P.S. On the other hand, if we're ever going to deal with machines where say each bit can have 3 or 4 values, as some hardware supports, maybe Blob can have a more generic interpretation as not just being binary bits; in that case, its more of a string of uints. But its still distinct from Buf in being immutable.

     Hash        Perl hash
-    KeyHash     Perl hash that autodeletes values matching default
     KeySet      KeyHash of Bool (does Set in list/array context)
     KeyBag      KeyHash of UInt (does Bag in list/array context)
     Pair        A single key-to-value association
-    Mapping     Set of Pairs with no duplicate keys
+    PairSet     A Set of Pairs

With the PairSet description, you should keep the "with no duplicate keys" part, same as with PairValSet.

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

Thank you. -- Darren Duncan

Reply via email to