pugs-comm...@feather.perl6.nl wrote:
Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502
Log:
[S02,S03,S32]
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:
0b'1100100101'
0o'57013'
0x'DEADBEEF'
:2'1100100101'
:8'57013'
:16'DEADBEEF'
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
