FAQ
Author: lwall
Date: 2009-09-29 19:50:27 +0200 (Tue, 29 Sep 2009)
New Revision: 28502

Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S32-setting-library/Containers.pod
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


Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
--- docs/Perl6/Spec/S02-bits.pod 2009-09-29 17:43:15 UTC (rev 28501)
+++ docs/Perl6/Spec/S02-bits.pod 2009-09-29 17:50:27 UTC (rev 28502)
@@ -13,8 +13,8 @@

Created: 10 Aug 2004

- Last Modified: 20 Sep 2009
- Version: 180
+ Last Modified: 29 Sep 2009
+ Version: 181

This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -622,6 +622,23 @@

=item *

+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
+ Numeric
+ Real
+ Integral
+ Callable
+ Positional
+ Associative
+
+=item *
+
Perl 6 intrinsically supports big integers and rationals through its
system of type declarations. C<Int> automatically supports promotion
to arbitrary precision, as well as holding C<Inf> and C<NaN> values.
@@ -641,6 +658,8 @@
may also be explicitly cast to C<Num>. (Also, if either side is
C<Num> already, C<< infix:</> >> gives you a C<Num> instead of a C<Rat>.)

+C<Rat> and C<Num> both do the C<Real> role.
+
Lower-case types like C<int> and C<num> imply the native
machine representation for integers and floating-point numbers,
respectively, and do not promote to arbitrary precision, though
@@ -971,8 +990,20 @@
Failure Failure (lazy exceptions, thrown if not handled properly)

Whenever you declare any kind of type, class, module, or package, you're
-automatically declaring a undefined prototype value with the same name.
+automatically declaring a undefined prototype value with the same name, known
+as the I<type object>. The name itself returns that type object:

+ Object Perl 6 object (default block parameter type, either Any or junction)
+ Any Perl 6 object (default routine parameter type, excludes junction)
+ Int Any Int object
+ Widget Any Widget object
+
+Type objects stringify to their name with empty parens concatenated.
+Note that type objects are not classes, but may be used to name
+classes:
+
+ Widget.new() # create a new Widget
+
Whenever a C<Failure> value is put into a typed container, it takes
on the type specified by the container but continues to carry the
C<Failure> role. (The C<undef> function merely returns the most
@@ -1028,11 +1059,11 @@
if and only if their types and contents are identical (that is, if
C<$x.WHICH> eqv C<$y.WHICH>).

+ 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.)
- Str Perl string (finite sequence of Unicode characters)
- Num Perl number
- Rat Perl rational
+ Num Perl number (approximate Real)
+ Rat Perl rational (exact Real)
Complex Perl complex number
Bool Perl boolean
Exception Perl exception
@@ -1042,7 +1073,10 @@
Range A pair of Ordered endpoints
Set Unordered collection of values that allows no duplicates
Bag Unordered collection of values that allows duplicates
+ PairVal An immutable Pair
+ PairValSet Set of PairVals with no duplicate keys
Signature Function parameters (left-hand side of a binding)
+ Parcel List of syntactic objects
Capture Function call arguments (right-hand side of a binding)
Blob An undifferentiated mass of bits
Instant A point on the continuous atomic timeline (TAI)
@@ -1073,6 +1107,33 @@
a steady time base, such as POSIX systems, will simply have to make
their best guess as to the correct atomic time.

+These types do (at least) the following roles:
+
+ Class Roles
+ ===== =====
+ Str Stringy
+ Bit Numeric Boolean
+ Int Numeric Integral
+ Num Numeric Real
+ Rat Numeric Real
+ Complex Numeric
+ Bool Boolean
+ Exception Failure
+ Block Callable
+ List Iterable
+ Seq Iterable
+ Range Iterable
+ Set Associative[Bool]
+ Bag Associative[UInt]
+ PairVal Associative
+ PairValSet Associative
+ Signature
+ Parcel Positional
+ Capture Positional Associative
+ Blob
+ Instant Real
+ Duration Real
+
=head2 Mutable types

Objects with these types have distinct C<.WHICH> values that do not change
@@ -1082,11 +1143,10 @@
Scalar Perl scalar
Array Perl array
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
Buf Perl buffer (a stringish array of memory locations)
IO Perl filehandle
Routine Base class for all wrappable executable objects
@@ -1096,15 +1156,9 @@
Macro Perl compile-time subroutine
Regex Perl pattern
Match Perl match, usually produced by applying a pattern
- Package Perl 5 compatible namespace
- Module Perl 6 standard namespace
- Class Perl 6 standard class namespace
- Role Perl 6 standard generic interface/implementation
- Grammar Perl 6 pattern matching namespace
- Any Perl 6 object (default routine parameter type, excludes junction)
- Object Perl 6 object (default block parameter type, either Any or junction)
+ STASH A symbol table hash (package, module, class, lexpad, etc)

-A C<KeyHash> differs from a normal C<Hash> in how it handles default
+The C<KeyHash> role differs from a normal C<Associative> hash in how it handles default
values. If the value of a C<KeyHash> element is set to the default
value for the C<KeyHash>, the element is deleted. If undeclared,
the default default for a C<KeyHash> is 0 for numeric types, C<False>
@@ -1139,12 +1193,32 @@
replicated the number of times specified by its corresponding value.
(Use C<.kv> or C<.pairs> to suppress this behavior in list context.)

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

+The following roles are supported:
+
+ Scalar
+ Array Positional
+ Hash Associative
+ KeySet KeyHash[Bool]
+ KeyBag KeyHash[UInt]
+ Pair Associative
+ PairSet Associative
+ Buf Stringy
+ IO
+ Routine Callable
+ Sub Callable
+ Method Callable
+ Submethod Callable
+ Macro Callable
+ Regex Callable
+ Match Positional Associative
+ STASH Associative
+
=head2 Value types

Explicit types are optional. Perl variables have two associated types:
@@ -1442,7 +1516,7 @@
role implies the ability to support C<< postcircumfix:<[ ]> >>.

Likewise, C<%x> may be bound to any object that does the C<Associative>
-role, such as C<Pair>, C<Mapping>, C<Set>, C<Bag>, C<KeyHash>, or
+role, such as C<Pair>, C<PairSet>, C<Set>, C<Bag>, C<KeyHash>, or
C<Capture>. The C<Associative> role implies the ability to support
C<< postcircumfix:<{ }> >>.


Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod 2009-09-29 17:43:15 UTC (rev 28501)
+++ docs/Perl6/Spec/S03-operators.pod 2009-09-29 17:50:27 UTC (rev 28502)
@@ -14,8 +14,8 @@

Created: 8 Mar 2004

- Last Modified: 21 Sep 2009
- Version: 173
+ Last Modified: 29 Sep 2009
+ Version: 174

=head1 Overview

@@ -611,8 +611,8 @@

Unlike in Perl 5, where C<+> is a no-op, this operator coerces to
numeric context in Perl 6. (It coerces only the value, not the
-original variable.) For values that are not already considered
-numeric, the narrowest appropriate type of C<Int>, C<Num>, or
+original variable.) For values that do not already do the
+C<Numeric> role, the narrowest appropriate type of C<Int>, C<Num>, or
C<Complex> will be returned; however, string containing two integers
separated by a C</> will be returned as a C<Rat>. Exponential notation
and radix notations are recognized.
@@ -631,8 +631,10 @@

~$x

-Coerces the value to a string. (It only coerces the value, not the
-original variable.)
+Coerces the value to a string, if it does not already do the C<Stringy>
+role. (It only coerces the value, not the original variable.) As with
+numerics, it is guaranteed only to coerce to something C<Stringy>,
+not necessarily C<Str>.

=item *

@@ -3247,8 +3249,8 @@
Any .<...> hash value slice truth ?all(X) i.e. ?all(.<...>)

Any Bool simple truth X
- Any Num numeric equality +$_ == X
- Any Str string equality ~$_ eq X
+ Any Numeric numeric equality +$_ == X
+ Any Stringy string equality ~$_ eq X

Hash Pair test hash mapping $_{X.key} ~~ X.value
Any Pair test object attribute ?."{X.key}" === ?X.value (e.g. filetests)

Modified: docs/Perl6/Spec/S32-setting-library/Containers.pod
===================================================================
--- docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-09-29 17:43:15 UTC (rev 28501)
+++ docs/Perl6/Spec/S32-setting-library/Containers.pod 2009-09-29 17:50:27 UTC (rev 28502)
@@ -19,8 +19,8 @@

Created: 19 Feb 2009 extracted from S29-functions.pod

- Last Modified: 12 May 2009
- Version: 8
+ Last Modified: 29 Sep 2009
+ Version: 9

The document is a draft.

@@ -719,7 +719,7 @@
=head1 Classes

This documents Buf, List, Seq, Range, Set, Bag, Junction, Array, Hash, KeyHash, KeySet,
-KeyBag, Pair, and Mapping.
+KeyBag, Pair, and PairSet.

=head2 Seq

@@ -809,13 +809,20 @@

=back

-=head2 Mapping
+=head2 PairValSet

- class Mapping does Associative {...}
+ class PairValSet does Associative {...}

An immutable hash value, essentially. The keys may
not contain duplicates, while the values may.

+=head2 PairSet
+
+ class PairSet does Associative {...}
+
+A hash value that is mutable only in values. The keys may
+not contain duplicates, while the values may.
+
=head2 Set

class Set does Associative {...}
@@ -869,9 +876,9 @@

=head2 KeyHash

- class KeyHash does Associative {...}
+ role KeyHash[::T $t, $default = 0] does Associative {...}

-A KeyHash represents a mutable set of values, represented as the keys
+A C<KeyHash> represents a mutable set of values, represented as the keys
of a C<Hash>. When asked to behave as a list it ignores its values
and returns only C<.keys>. C<KeySet> and C<KeyBag> are derived from
this type, but constrain their values to be C<Bool> and C<UInt>,

Search Discussions

  • Darren Duncan at Sep 29, 2009 at 8:54 pm

    pugs-commits@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
  • Jon Lang at Sep 29, 2009 at 9:26 pm

    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
  • Darren Duncan at Sep 29, 2009 at 9:44 pm

    Jon Lang wrote:
    Darren Duncan wrote:
    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~
    Well, sure, if its useful; the idea is to amalgam numeric and Str syntax.
    However, because a Blob literal presumably just has 0..9,A-Z,_ characters in its
    payload, one of the main uses of custom delimiter flexibility, which is avoiding
    conflicts with payload elements, isn't necessary.
    -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.
    I was never under the assumption that Mapping was Positional; it was an
    immutable Hash essentially, and both were associative not ordered. So Mapping
    was renamed to PairValSet, and PairSet was added as a mutable alternative, hence
    how the latter differs from Hash is the question. I think only Capture et al
    are both associative and ordered. If you want an ordered list of Pair, I don't
    think that has its own type otherwise, but you can parameterize one from
    Seq/Array/etc.

    -- Darren Duncan
  • Jon Lang at Sep 29, 2009 at 9:57 pm

    Darren Duncan wrote:
    Jon Lang wrote:
    So what about custom delimiters?

    q:2<1100100101>
    q:8[57013]
    q:16~DEADBEEF~
    Well, sure, if its useful; the idea is to amalgam numeric and Str syntax.
    However, because a Blob literal presumably just has 0..9,A-Z,_ characters in
    its payload, one of the main uses of custom delimiter flexibility, which is
    avoiding conflicts with payload elements, isn't necessary.
    True enough. OTOH, I've also used custom delimiters for visual distinction.
    -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.
    I was never under the assumption that Mapping was Positional; it was an
    immutable Hash essentially, and both were associative not ordered.  So
    Mapping was renamed to PairValSet, and PairSet was added as a mutable
    alternative, hence how the latter differs from Hash is the question.  I
    think only Capture et al are both associative and ordered.  If you want an
    ordered list of Pair, I don't think that has its own type otherwise, but you
    can parameterize one from Seq/Array/etc.
    Note that before this most recent change, the document read as "As
    with C<Hash> types, C<Pair> and C<Mapping> are mutable in their values
    but not in their keys." Now it reads as "As with C<Hash> types,
    C<Pair> and C<PairSet> are mutable in their values but not in their
    keys." I may be wrong about what the difference between a Mapping and
    a Hash used to be; but the above says that Mapping was mutable in its
    values, not immutable; and that it was replaced by PairSet, not Pair.
    Presumably, there was already something in place to differentiate a
    Mapping from a Hash; and whatever that difference was, it still
    applies to PairSet vs. Hash (which would possibly make PairSet a poor
    choice of names, depending on the difference).

    --
    Jonathan "Dataweaver" Lang

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language @
categoriesperl
postedSep 29, '09 at 5:50p
activeSep 29, '09 at 9:57p
posts5
users3
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase