Author: larry
Date: Mon Jan 8 02:35:42 2007
New Revision: 13519
Modified:
doc/trunk/design/syn/S03.pod
Log:
A bunch more "tough love" applied to the smartmatching semantics.
Change $x notation to X notation to better reflect metasyntactic nature.
Num and Str as patterns now consistently force + and ~ context for
optimizability. They no longer "autogrep" anything.
Arrays now always notionally match the entire list, but can use * as wildcard.
Added table of deprecated semantics and new notations to get the same effect
using pattern retyping, * wildcarding, or just ordinary methods.
Attempted to clarify when buffers can be used as strings.
Renamed LazyStr to LazyCat, which now only cats in string context.
Unified treatment of sets and hash keys under junctive methods.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podMon Jan 8 02:35:42 2007
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 7 Jan 2007
+ Last Modified: 8 Jan 2007
Number: 3
- Version: 86
+ Version: 87
=head1 Changes to Perl 5 operators
@@ -601,7 +601,7 @@
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 C,
-or to any other topicalizer. C<$x> represents the pattern to be
+or to any other topicalizer. C represents the pattern to be
matched against on the right side of C<~~>, or after a C.
The first section contains privileged syntax; if a match can be done
@@ -615,105 +615,80 @@
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.
+method belonging to the C 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
+pattern's form or type (the C 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 C 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 $_
+$_X Type of Match Implied Match if (given $_)
+=== = ===
+Any Code:($) scalar sub truthX($_)
+Any Code:() simple closure truthX() (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 string contains char$_.ma
