[svn:perl6-synopsis] r13487 - doc/trunk/design/syn
la...@cvs.perl.org
Date: Wed Nov 29 09:20:50 2006
New Revision: 13487
Modified:
doc/trunk/design/syn/S01.pod
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S05.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S09.pod
doc/trunk/design/syn/S10.pod
doc/trunk/design/syn/S11.pod
doc/trunk/design/syn/S12.pod
doc/trunk/design/syn/S13.pod
doc/trunk/design/syn/S17.pod
doc/trunk/design/syn/S29.pod
Log:
More entries in smartmatch table.
Added vim modelines to help perpetuate audreyt++'s expandtabs.
Modified: doc/trunk/design/syn/S01.pod
==============================================================================
--- doc/trunk/design/syn/S01.pod (original)
+++ doc/trunk/design/syn/S01.pod Wed Nov 29 09:20:50 2006
@@ -161,3 +161,5 @@
into a coherent whole.
=back
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S02.pod
==============================================================================
--- doc/trunk/design/syn/S02.pod (original)
+++ doc/trunk/design/syn/S02.pod Wed Nov 29 09:20:50 2006
@@ -2420,3 +2420,5 @@
Any category containing "circumfix" requires two token arguments, supplied
in slice notation.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S03.pod
==============================================================================
--- doc/trunk/design/syn/S03.pod (original)
+++ doc/trunk/design/syn/S03.pod Wed Nov 29 09:20:50 2006
@@ -14,7 +14,7 @@
Date: 8 Mar 2004
Last Modified: 13 Nov 2006
Number: 3
- Version: 75
+ Version: 76
=head1 Changes to Perl 5 operators
@@ -582,8 +582,10 @@
$_ $x Type of Match Implied Matching Code
====== ===== ===================== =============
Any Code:($) scalar sub truth match if $x($_)
- Hash Hash hash keys identical match if $_.keys.sort »eq« $x.keys.sort
- Hash any(Hash) hash key intersection match if $_{any(Hash.keys)}
+ Hash Hash hash keys identical match if $_.keys === $x.keys
+ Hash Set members identical match if $_.keys === $x
+ Set Set members identical match if $_ === $x
+ Hash any(Hash) hash key intersection match if exists $_{any(Hash.keys)}
Hash Array hash value slice truth match if $_{any(@$x)}
Hash any(list) hash key slice existence match if exists $_{any(list)}
Hash all(list) hash key slice existence match if exists $_{all(list)}
@@ -596,9 +598,13 @@
Array Regex array grep match if any(@$_) ~~ /$x/
Array Num array contains number match if any($_) == $x
Array Str array contains string match if any($_) eq $x
+ Array Buf array equivalent to buf match if $_ eqv Array($x)
+ Array Set array equivalent to set match if Set($_) === $x
+ Array Any array contains item* match if any($_) === $x
Array .[number] array element truth* match if $_[number]
Num NumRange in numeric range match if $min <= $_ <= $max
Str StrRange in string range match if $min le $_ le $max
+ Any Range in range match if $min !after $_ !after $max
Capture Signature parameter binding match if $cap can bind to $sig
Code Signature signature compatibility* match if $_ is a subset of $x
Signature Signature signature compatibility match if $_ is a subset of $x
@@ -1699,3 +1705,4 @@
Comma is the only listop that is allowed to occur where an operator is
expected. All other listops function as a term within the list to the left.
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S04.pod
==============================================================================
--- doc/trunk/design/syn/S04.pod (original)
+++ doc/trunk/design/syn/S04.pod Wed Nov 29 09:20:50 2006
@@ -985,3 +985,5 @@
to see transient variables in their current lexical scope, so their
cloning status depends at least on the cloning status of the block
they're in.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S05.pod
==============================================================================
--- doc/trunk/design/syn/S05.pod (original)
+++ doc/trunk/design/syn/S05.pod Wed Nov 29 09:20:50 2006
@@ -3071,3 +3071,5 @@
@array».match($regex);
=back
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S06.pod
==============================================================================
--- doc/trunk/design/syn/S06.pod (original)
+++ doc/trunk/design/syn/S06.pod Wed Nov 29 09:20:50 2006
@@ -2653,3 +2653,5 @@
If a switch of the form C<-abc> cannot be matched against any
particular parameter, an attempt will be made to match it as if it
had been written C<-a -b -c>.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S09.pod
==============================================================================
--- doc/trunk/design/syn/S09.pod (original)
+++ doc/trunk/design/syn/S09.pod Wed Nov 29 09:20:50 2006
@@ -763,3 +763,4 @@
This rule applies to C<Array>, C<Hash>, and C<Scalar> container objects.
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S10.pod
==============================================================================
--- doc/trunk/design/syn/S10.pod (original)
+++ doc/trunk/design/syn/S10.pod Wed Nov 29 09:20:50 2006
@@ -185,3 +185,5 @@
or maybe even just:
our &AUTODEF ::= &BUILD;
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S11.pod
==============================================================================
--- doc/trunk/design/syn/S11.pod (original)
+++ doc/trunk/design/syn/S11.pod Wed Nov 29 09:20:50 2006
@@ -360,3 +360,5 @@
specified already implies it, such as use of a "C<#!/usr/bin/perl6>"
shebang line. Nor is it necessary to force Perl 6 in any file that
begins with the "class" or "module" keywords.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S12.pod
==============================================================================
--- doc/trunk/design/syn/S12.pod (original)
+++ doc/trunk/design/syn/S12.pod Wed Nov 29 09:20:50 2006
@@ -1737,3 +1737,5 @@
sometimes relies on this ability to determine whether a superclass supplies
a method of a particular name if it's required and hasn't been supplied
by the class or one of its roles.
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S13.pod
==============================================================================
--- doc/trunk/design/syn/S13.pod (original)
+++ doc/trunk/design/syn/S13.pod Wed Nov 29 09:20:50 2006
@@ -129,3 +129,5 @@
because the multi dispatch cares only about the class.
=cut
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S17.pod
==============================================================================
--- doc/trunk/design/syn/S17.pod (original)
+++ doc/trunk/design/syn/S17.pod Wed Nov 29 09:20:50 2006
@@ -26,3 +26,5 @@
=head1 Universal Asynchronous I/O
=head1 Timers and Timeouts
+
+=for vim:set expandtab sw=4:
Modified: doc/trunk/design/syn/S29.pod
==============================================================================
--- doc/trunk/design/syn/S29.pod (original)
+++ doc/trunk/design/syn/S29.pod Wed Nov 29 09:20:50 2006
@@ -19,4 +19,4 @@
http://svn.openfoundry.org/pugs/docs/Perl6/Spec/Functions.pod
-
+=for vim:set expandtab sw=4:
Smylers
> Log:
> More entries in smartmatch table.
>
> +++ doc/trunk/design/syn/S03.pod Wed Nov 29 09:20:50 2006
> + Hash Hash hash keys identical match if $_.keys === $x.keys
> + Hash Set members identical match if $_.keys === $x
> + Set Set members identical match if $_ === $x
> + Hash any(Hash) hash key intersection match if exists $_{any(Hash.keys)}
Should that last one have a C<$x> in the code somewhere?
Smylers
TSa
la...@cvs.develooper.com wrote:
> $_ $x Type of Match Implied Matching Code
> ====== ===== ===================== =============
> + Set Set members identical match if $_ === $x
> + Array Set array equivalent to set match if Set($_) === $x
Isn't it better to define these in terms of Bags? I mean with
Bag a supertype of Set the dispatch should go to cases
&infix<===>:(Bag,Bag), &infix<===>:(Bag,Set), &infix<===>:(Set,Bag)
and &infix<===>:(Set,Set).
Regards, TSa.
--
Larry Wall
: HaloO,
I think that most Perl programmers would rather view Sets and Bags through
the Hash lens, so I think I'm going to try to avoid mentioning Sets and Bags
in the smartmatching table entirely, and only differentiate KeyHash, if
we differentiate anything. In this view all of Set, Bag, KeySet and KeyBag
are really KeyHash, which is a Hash that is being used primarily for its
keys. Set and Bag just happen to be constant values of KeySet and KeyBag
that also happen to override === and .WHICH to provide value rather
than object semantics.
I think a consequence of this view is that (x) ops are all key-based set
ops unless you explicitly make sure both sides are bags. But it's still
early enough in the morning that I've not thought this through entirely...
What I do know this early is that we can't turn the hardwired
smartmatch table into a complete crossbar of every type combination
we can think up now and in the future. For learnability we've got
to keep it linear somehow. That's my main motivation for trying to
smash Set and Bag into being variants of the Hash role.
Larry
TSa
you wrote:
> I think a consequence of this view is that (x) ops are all key-based set
> ops unless you explicitly make sure both sides are bags. But it's still
> early enough in the morning that I've not thought this through entirely...
I understand that you want first of all 'KeyHash does Hash' and then
we have three special key handling subtypes of Hash. They differ only
in the value type. With Bit <: UInt <: Any and covariant container
typing this yields KeySet <: KeyBag <: KeyHash <: Hash. And I still
opt for Seq/List/Array entering the picture as subtypes of KeyBag
because we loose no information then.
The question is now how the mixed value case Bit and UInt from
the respective KeySet and KeyBag types are handled. I think we
should promote the Bit to an Uint and go for Bag operations. Note
that Bag operations yield set semantics when fed with set data.
The subtyping of KeyBag to KeyHash is a bit bogus because we loose
Bag semantics in so far as the Any supertype of UInt is not a
generalized multiplicity. That is KeyHash is more like KeySet but
with arbitrary items indicating presence. Actuallly the Any type
might support the needed min/max and +/- calls but I guess this is
not what a user of a KeyHash would expect when she uses it as argument
to the (x) ops.
In the end it might be more practical to make Bag an interface
subtype of Set that adds multiplicity of items that is dropped
when mixed Set Bag (x) ops are used. This is where I started before
Darren mentioned the Set <: Bag fact.
Is that enough food for thought for later in the day?
Regards, TSa.
--
Darren Duncan
Tsa,
I consider the current KeyHash|KeySet|KeyBag|Set|Bag etc in Synopsis
6 to be a good solution for users of sets and bags.
I do not understand the rationale to make any further changes as you
have described above.
Please clarify benefits of what you are debating to change, maybe
with use case examples.
-- Darren Duncan
TSa
you wrote:
> I consider the current KeyHash|KeySet|KeyBag|Set|Bag etc in Synopsis 6
> to be a good solution for users of sets and bags.
They are fine as far as the definition goes. But I guess it
intentionally leaves certain things unmentioned.
> I do not understand the rationale to make any further changes as you
> have described above.
First of all I like to discuss type system matters. I'm not aiming
at further changes to the synopsis but a clarification on the list.
> Please clarify benefits of what you are debating to change, maybe with
> use case examples.
I see a dilemma concerning the subtype relation of Bag and Set. There
can either be 'Set does Bag' or 'Bag does Set'. The former is the
cleaner solution, the latter prioritizes Set operations for the (x)
ops. The question how the Set and Bag types are related to Seq is also
not fully defined.
The coolest solution would be to have Bag in a module from where it
supertypes Set when used. In this way you get the (x) to mean set
operations unless a 'use Bag' is in scope. This supertyping approach
would allow further Set supertypes like FuzzySet. But I don't know
what the syntax looks like. Also combining these Set supertype modules
might proof difficult. Once again 'FuzzySet does Set' could be more
practical.
BTW, are the KeyHash, KeySet and KeyBag container types forced into
hash sigiled variables? That is
my %kh is KeyHash;
my %ks is KeySet;
my %kb is KeyBag;
Regards, TSa.
--
Darren Duncan
>The coolest solution would be to have Bag in a module from where it
>supertypes Set when used. In this way you get the (x) to mean set
>operations unless a 'use Bag' is in scope. This supertyping approach
>would allow further Set supertypes like FuzzySet. But I don't know
>what the syntax looks like. Also combining these Set supertype modules
>might proof difficult. Once again 'FuzzySet does Set' could be more
>practical.
What you mention reminds me of the "use integer" pragma of Perl 5.
>BTW, are the KeyHash, KeySet and KeyBag container types forced into
>hash sigiled variables? That is
>
> my %kh is KeyHash;
> my %ks is KeySet;
> my %kb is KeyBag;
I would expect that, like with ordinary Hashes, that I can use all of
the above with $ sigiled variables (which is my preference in fact)
or % sigiled variables, and the difference of semantics would be the
same as with the Hash; a %foo = %bar would copy all the elements,
while $foo = $bar would not.
-- Darren Duncan