[svn:perl6-synopsis] r13512 - doc/trunk/design/syn
Author: luqui Date: Sat Jan 6 15:22:29 2007 New Revision: 13512 Modified: doc/trunk/design/syn/S03.pod Log: Fixed an error in the prefix | discussion. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSat Jan 6 15:22:29 2007 @@ -1560,7 +1560,7 @@ signature, but the presence of C| defers that test until run time for that argument (and for any subsequent arguments): -my @args := @foo, @bar; +my @args := [EMAIL PROTECTED], @bar]; push |@args; is equivalent to:
[svn:perl6-synopsis] r13513 - doc/trunk/design/syn
Author: luqui Date: Sat Jan 6 15:28:54 2007 New Revision: 13513 Modified: doc/trunk/design/syn/S03.pod Log: Fixed my fix. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSat Jan 6 15:28:54 2007 @@ -1560,7 +1560,7 @@ signature, but the presence of C| defers that test until run time for that argument (and for any subsequent arguments): -my @args := [EMAIL PROTECTED], @bar]; +my @args := [item @foo, item @bar]; push |@args; is equivalent to:
[svn:perl6-synopsis] r13514 - doc/trunk/design/syn
Author: luqui Date: Sat Jan 6 15:33:09 2007 New Revision: 13514 Modified: doc/trunk/design/syn/S03.pod Log: Ugh. r3 of this simple change. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podSat Jan 6 15:33:09 2007 @@ -1560,7 +1560,7 @@ signature, but the presence of C| defers that test until run time for that argument (and for any subsequent arguments): -my @args := [item @foo, item @bar]; +my @args := [item @foo, @bar]; push |@args; is equivalent to:
Re: Patterns
Larry Wall wrote:
Anyway, that gives us:
given $pattern {
when .accepts(42) {...}
}
which given typical usage patterns of switch statements is probably
adequately huffmanized, unless we want to go for something shorter
than accepts/rejects, like
acc/rej
pix/nix
ok/bogus
...at which point, legibility becomes an issue. .accepts() and
.rejects() seem to work well enough on a case-by-case basis - although
it occurs to me that someone who intends to put the pattern first
within a given/when construct is probably going to want to do so for
every case, or very nearly so:
given $pattern {
when .accepts($a) { ... }
when .accepts($b) { ... }
when .accepts($c) { ... }
when .accepts($d) { ... }
}
It would be nice if there were some way to factor out the .accepts()
in the above code. Maybe something like:
given $pattern {
when $a { ... } # if $a ~~ $pattern { ... ; next }
when $b { ... } # if $b ~~ $pattern { ... ; next }
when $c { ... } # if $c ~~ $pattern { ... ; next }
when $d { ... } # if $d ~~ $pattern { ... ; next }
} is backward;
Although I don't like the fact that you have to wait until reading the
whole block to find out that the cases are being processed inside-out.
--
Would it be possible to put a closure on the left and an argument list
on the right, with the effect being that the closure gets called using
the argument list? This would let you do something like:
given { ^x ~~ $pattern } {
when $a { ... } # if $a ~~ $pattern { ... ; next }
when $b { ... } # if $b ~~ $pattern { ... ; next }
when $c { ... } # if $c ~~ $pattern { ... ; next }
when $d { ... } # if $d ~~ $pattern { ... ; next }
}
or
given { ^x = $number ^y } {
when 1, 2 { ... } $ if 1 = $number 2 { ... ; next }
when 2, 3 { ... } $ if 2 = $number 3 { ... ; next }
}
(Yes, I know that this second case could be handled more flexibly
using right-side Ranges. TIMTOWTDI.)
The main problem that I have with this idea is its rigidity. The
_only_ way that the topic can be used in the above is as a test for
the 'when' clauses; and it messes with the 'when *' idiom. (But then,
any code that follows the final 'when' in a block is already the 'if
all else fails...' code; 'when *' is merely syntactic sugar to
highlight this fact.)
--
It would be nice to have something that is to 'given' as 'loop' is to
'for', letting you specify a topic and a separate case tester up
front:
test $pattern, { $^x ~~ $_ } {
when $a { ... } # if $a ~~ $pattern { ... ; next }
when $b { ... } # if $b ~~ $pattern { ... ; next }
when $c { ... } # if $c ~~ $pattern { ... ; next }
when $d { ... } # if $d ~~ $pattern { ... ; next }
}
Or, to avoid additional keywords, just say that a 'given' statement
with two arguments uses the first argument as its topic and the second
argument as the case tester to replace '{ $_ ~~ $^x }' in 'when'
clauses. Better, use 'when' as is, but introduce a 'test' alternative
that is customized by the second parameter:
given $pattern, { $^x ~~ $_ } {
test $a { ... } # if $a ~~ $pattern { ... ; next }
test $b { ... } # if $b ~~ $pattern { ... ; next }
test $c { ... } # if $c ~~ $pattern { ... ; next }
test $d { ... } # if $d ~~ $pattern { ... ; next }
when * { ... } # if $pattern ~~ * { ... ; next }
}
That way, 'given' and 'when' still behave exactly as currently
described; the case tester only comes into play when you explicitly
ask for it.
--
At this point, though, the case tester is looking like it might be
better as a property of the 'given' block:
given $pattern {
TEST { $^x ~~ $_ }
test $a { ... } # if $a ~~ $pattern { ... ; next }
test $b { ... } # if $b ~~ $pattern { ... ; next }
test $c { ... } # if $c ~~ $pattern { ... ; next }
test $d { ... } # if $d ~~ $pattern { ... ; next }
when * { ... } # if $pattern ~~ * { ... ; next }
}
Or go ahead and let TEST change the behavior of 'when' within the
block, and rely on nested blocks to allow different kinds of tests
within a 'given' block:
given $pattern
{
{
TEST - $x { $x ~~ $_ }
when $a { ... } # if $a ~~ $pattern { ... ; next }
when $b { ... } # if $b ~~ $pattern { ... ; next }
when $c { ... } # if $c ~~ $pattern { ... ; next }
when $d { ... } # if $d ~~ $pattern { ... ; next }
}
when * { ... } # if $pattern ~~ * { ... ; next }
}
...and someone silly enough to want to frequently change the case
tester within a given block is advised to use 'if' instead.
What do you think?
--
Jonathan Dataweaver Lang
Re: Patterns
On 1/5/07, Larry Wall [EMAIL PROTECTED] wrote:
Anyway, that gives us:
given $pattern {
when .accepts(42) {...}
}
I think this type of usage should be encouraged with a bit more
huffmanization. My first thought would be to add Cagainst to invert
the arguments to ~~ versus Cwith.
given @something {
when $this { ... }# @something ~~ $this
against $that { ... }# $that ~~ @something
}
That would help keep the ~~ DWIM table from trying to guess on which
side you really wanted @something on.
- Ashley Winters
[svn:perl6-synopsis] r13515 - doc/trunk/design/syn
Author: larry
Date: Sun Jan 7 00:50:30 2007
New Revision: 13515
Modified:
doc/trunk/design/syn/S03.pod
Log:
Smartmatching is now hopefully more consistent, extensible, and optimizable.
(Suggestion to use single dispatch semantics on pattern was from luqui++.)
After single dispatch, pattern can then choose to multi-dispatch the topic.
The new table is just the first whack at matching under new rules, so please
consider the individual entries and their semantics to still be negotiable.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podSun Jan 7 00:50:30 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 4 Jan 2007
+ Last Modified: 6 Jan 2007
Number: 3
- Version: 83
+ Version: 84
=head1 Changes to Perl 5 operators
@@ -596,87 +596,221 @@
=head1 Smart matching
-Below is the current table of smart matches. The list is intended
-to reflect forms that can be recognized at compile time. To avoid
-explosion of options, the following types are remapped for the
-compile-time lookup only:
+Here is the table of smart matches for standard Perl 6
+(that is, the dialect of Perl in effect at the start of your
+compilation unit). Smart matching is generally done on the current
+topic, that is, on C$_. In the table below, C$_ represents the
+left side of the C~~ operator, or the argument to a Cgiven,
+or to any other topicalizer. C$x represents the pattern to be
+matched against on the right side of C~~, or after a Cwhen.
+
+The first section contains privileged syntax; if a match can be done
+via one of those entries, it will be. These special syntaxes are
+dispatched by their form rather than their type. Otherwise the rest
+of the table is used, and the match will be dispatched according to
+the normal method dispatch rules. The optimizer is allowed to assume
+that no additional match operators are defined after compile time,
+so if the pattern types are evident at compile time, the jump table
+can be optimized. However, the syntax of this part of the table
+is still somewhat privileged, insofar as the C~~ operator is one
+of the few operators in Perl that does not use multiple dispatch.
+Instead, type-based smart matches singly dispatch to an underlying
+method belonging to the C$x pattern object.
+
+In other words, smart matches are dispatched first on the basis of the
+pattern's form or type (the C$x below), and then that pattern itself
+decides whether and how to pay attention to the type of the topic
+(C$_). So the second column below is really the primary column.
+The CAny entries in the first column indicate a pattern that either
+doesn't care about the type of the topic, or that picks that entry
+as a default because the more specific types listed above it didn't match.
+
+$_$xType of Match Implied Match if
+=== = =
+Any Code:($) scalar sub truth$x($_)
+Any Code:() simple closure truth$x() (ignoring $_)
+Any undef undefined not defined $_
+Any * block signature match block successfully binds to |$_
+Any .foo method truth?any($_.foo)
+Any .foo(...) method truth?any($_.foo(...))
+Any .(...)list sub call truth ?any($_(...))
+Any .[...]array value slice truth ?any($_[...])
+Any .{...}hash value slice truth ?any($_{...})
+Any hash value slice truth ?any($_...)
+
+Any Bool simple truth$x.true given $_
+
+Num Num numeric equality+$_ == $x
+Capture Num numeric equality+$_ == $x
+Array Num array contains number any(@$_) == $x
+Hash Num hash key existence $_.exists($x)
+Byte Num numeric equality+$_ == $x
+Any Num numeric equality+$_ == $x
+
+Str Str string equality $_ eq $x
+Capture Str string equality ~$_ eq $x
+Array Str array contains string any(@$_) eq $x
+Hash Str hash key existence $_.exists($x)
+Byte Str string equality ~$_ eq $x
+Any Str string equality ~$_ eq $x
+
+Buf Buf buffer equality $_ eq $x
+Str Buf string equality $_ eq Str($x)
+Array Buf arrays are comparable $_ »===« @$x
+Hash Buf hash key existence $_.exists($x)
+Any Buf buffer equality Buf($_) eq $x
+
+Buf Byte buffer contains byte$_.match(/$x/)
+Str Byte string contains byteBuf($_).match(/$x/)
+
+Str Char
