[svn:perl6-synopsis] r13366 - doc/trunk/design/syn
Author: audreyt
Date: Wed Nov 1 07:51:52 2006
New Revision: 13366
Modified:
doc/trunk/design/syn/S01.pod
doc/trunk/design/syn/S11.pod
Log:
* S01 and S11: Per fglock++'s suggestion, add the "use v5;"
compatibility form, which can occur only at the beginning
of a lexical block:
use v6-alpha;
# ...some Perl 6 code...
{
use v5;
# ...some Perl 5 code...
{
use v6-alpha;
# ...more Perl 6 code...
}
}
Modified: doc/trunk/design/syn/S01.pod
==
--- doc/trunk/design/syn/S01.pod(original)
+++ doc/trunk/design/syn/S01.podWed Nov 1 07:51:52 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 14 Sept 2006
+ Last Modified: 1 Nob 2006
Number: 1
- Version: 4
+ Version: 5
This document originally summarized Apocalypse 1, which covers the
initial design concept. That original summary may be found below
@@ -113,6 +113,23 @@
=item *
+Migration in the other direction is also important. In Perl 6
+mode, one can drop back to Perl 5 mode with C at the
+beginning of a lexical block. Such blocks may be nested:
+
+use v6-alpha;
+# ...some Perl 6 code...
+{
+use v5;
+# ...some Perl 5 code...
+{
+use v6-alpha;
+# ...more Perl 6 code...
+}
+}
+
+=item *
+
Scaling is one of those areas where Perl needs to be multiparadigmatic
and context sensitive. Perl 5 code is not strict by default, while
Perl 6 code is. But it should be easy to relax with C<-e> or
Modified: doc/trunk/design/syn/S11.pod
==
--- doc/trunk/design/syn/S11.pod(original)
+++ doc/trunk/design/syn/S11.podWed Nov 1 07:51:52 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 6 Jul 2006
+ Last Modified: 1 Nov 2006
Number: 11
- Version: 14
+ Version: 15
=head1 Overview
@@ -341,6 +341,21 @@
a bare literal in a void context I to have produced a warning.
(Invoking perl with C<-e6> has the same effect.)
+In the other direction, to inline Perl 5 code inside a Perl 6 program, put
+C at the beginning of a lexical block. Such blocks can nest
arbitrarily
+deeply to switch between Perl versions:
+
+use v6-alpha;
+# ...some Perl 6 code...
+{
+use v5;
+# ...some Perl 5 code...
+{
+use v6-alpha;
+# ...more Perl 6 code...
+}
+}
+
It's not necessary to force Perl 6 if the interpreter or command
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
Re: mmd-draft.txt
在 Oct 26, 2006 10:26 AM 時，TSa 寫到： I figure that http://svn.openfoundry.org/pugs/docs/notes/multi_method_dispatch/ mmd-draft.txt hasn't made it into S06 yet. So what is the current state of affairs? The original plan was to have Larry review it in Brazil and check it in along with an implementation (or two), but that may have to wait a bit now that Larry can't make it to Brazil... Could someone explain me the voting mechanism mentioned in the document? I get that it works from left to right and compares the narrowness of types of the competing targets at that position. But what information is recorded on the score cards and how is that finally used in selecting the dispatch target? A variant's score cards only records two Boolean values for each variant: "voting" and "qualified". The final resolution is by consensus: After all the positions are processed, if all variants consider a single unique variant to be qualified, it is chosen. Otherwise an ambiguity error is raised. Thanks, Audrey
[svn:perl6-synopsis] r13371 - doc/trunk/design/syn
Author: larry
Date: Wed Nov 1 10:10:57 2006
New Revision: 13371
Modified:
doc/trunk/design/syn/S12.pod
Log:
Switched to explicit ;; for separating longest longname from subsequent args.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podWed Nov 1 10:10:57 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 27 Oct 2004
- Last Modified: 20 Oct 2006
+ Last Modified: 1 Nov 2006
Number: 12
- Version: 29
+ Version: 30
=head1 Overview
@@ -699,11 +699,16 @@
Sometimes you want to have parameters that aren't counted as part of the
long name. For instance, if you want to allow an optional "step" parameter
to your range operator, but not consider it for multi dispatch, then put a
-semicolon instead of a comma before it:
+double semicolon instead of a comma before it:
-multi sub infix:<..>(Int $min, Int $max; Int $by = 1) {...}
+multi sub infix:<..>(Int $min, Int $max;; Int $by = 1) {...}
+
+The double semicolon, if any, determines the complete long name of
+a multi. (In the absence of that, a double semicolon is assumed
+after the last declared argument, but before any return signature.)
+Note that a call to the routine must still be compatible with
+subsequent arguments.
-The final semicolon, if any, determines the complete long name of a multi.
However, a given multi may advertise multiple long names, some
of which are shorter than the complete long name. This is done by
putting a semicolon after each advertised long name (replacing the comma,
@@ -725,10 +730,11 @@
to be used as tiebreakers.
Conjecture: In order to specify dispatch that includes the return
-type context, it is necessary to place a semicolon after the return type:
+type context, it is necessary to place the return type before the double
+semicolon:
-multi infix:<..>(Int $min, Int $max; Int $by = 1 --> Iterator;) {...}
-multi infix:<..>(Int $min, Int $max; Int $by = 1 --> Selector;) {...}
+multi infix:<..>(Int $min, Int $max --> Iterator;; Int $by = 1) {...}
+multi infix:<..>(Int $min, Int $max --> Selector;; Int $by = 1) {...}
Note that such a declaration might have to delay dispatch until the
actual desired type is known! (Generally, you might just consider
@@ -881,10 +887,10 @@
}
If you want to parameterize the initial value of a role attribute,
-be sure to put a semicolon if you don't want the parameter to be considered
-part of the long name:
+be sure to put a double semicolon if you don't want the parameter to
+be considered part of the long name:
-role Pet[::ID; $tag] {
+role Pet[::ID;; $tag] {
has ID $.collar .= new($tag);
}
