Patch for S06 (and also S03)
Hi, there~
I've been reading S06 in the past few days. it almost killed me due to
its difficulties. ;-)
The patch to S06 (as well as S03) is given at the end of the mail.
I've also included several fixes from TreyHarris++ and spinclad++. I
really appreciate the help from #perl6. :D
There's one issue not reflected in the patch: I've got the feeling
that S06 is claiming the differences between the inner type of
return values and the of type over and over again, which even
annoyed me while I was reading. Maybe make it less verbose a bit?
On the other hand, I think the Unpacking tree node parameters
section needs more explanation. The Signature and Capture bits are
still fuzzy in my head after reading so many synopses.
Another uncertain issue is is assoc('chain') versus is
assoc('chaining'). S06 is giving a contradictory answer. I've changed
the 'chaining' tag to 'chain' in the patch, BTW.
Cheers,
Agent
Index: D:/projects/Perl6-Syn/S03.pod
===
--- D:/projects/Perl6-Syn/S03.pod (revision 10539)
+++ D:/projects/Perl6-Syn/S03.pod (working copy)
@@ -1009,7 +1009,7 @@
=head1 Junctive operators
C|, C, and C^ are no longer bitwise operators (see
-L/Changes to existing operators) but now serve a much higher cause:
+L/Changes to Perl 5 operators) but now serve a much higher cause:
they are now the junction constructors.
A junction is a single value that is equivalent to multiple values. They
Index: D:/projects/Perl6-Syn/S06.pod
===
--- D:/projects/Perl6-Syn/S06.pod (revision 10539)
+++ D:/projects/Perl6-Syn/S06.pod (working copy)
@@ -57,7 +57,7 @@
other constraints. They may have multliple invocants.
BPrototypes (keyword: Cproto) specify the commonalities (such
-as parameter names, fixity and associativity) shared by all multis
+as parameter names, fixity, and associativity) shared by all multis
of that name in the scope of the Cproto declaration.
A modifier keyword may occur before the routine keyword in a named routine:
@@ -98,7 +98,7 @@
our RETTYPE sub ( PARAMS ) TRAITS {...} # means the same as my here
BTrait is the name for a compile-time (Cis) property.
-See LTraits and Properties
+See LProperties and traits.
=head2 Perl5ish subroutine declarations
@@ -244,7 +244,7 @@
An operator name consists of a grammatical category name followed by
a single colon followed by an operator name specified as if it were
a hash subscript (but evaluated at compile time). So any of these
-indicate the same binary addition operator:
+indicates the same binary addition operator:
infix:+
infix:«+»
@@ -271,7 +271,7 @@
sub circumfix:LEFTDELIM RIGHTDELIM ($contents) {...}
sub circumfix:{'LEFTDELIM','RIGHTDELIM'} ($contents) {...}
-Contrary to A6, there is no longer any rule about splitting an even
+Contrary to Apocalypse 6, there is no longer any rule about splitting an even
number of characters. You must use a two element slice. Such names
are canonicalized to a single form within the symbol table, so you
must use the canonical name if you wish to subscript the symbol table
@@ -367,9 +367,9 @@
Only bare keys with valid identifier names are recognized as named arguments:
doit when = 'now'; # always a named arg
-doit 'when' = 'now'; # always a positonal arg
-doit 123 = 'now'; # always a positonal arg
-doit :123now; # always a positonal arg
+doit 'when' = 'now'; # always a positional arg
+doit 123 = 'now'; # always a positional arg
+doit :123now; # always a positional arg
Going the other way, pairs intended as named arguments that don't look
like pairs must be introduced with the C[,] reduction operator:
@@ -419,12 +419,13 @@
Ordinary hash notation will just pass the value of the hash entry as a
positional argument regardless of whether it is a pair or not.
-To pass both key and value out of hash as a positional pair, use C:p.
+To pass both key and value out of hash as a positional pair, use C:p
+instead:
doit %hasha:p,1,2,3;
doit %hash{'b'}:p,1,2,3;
-instead.. (The C:p stands for pairs, not positional--the
+(The C:p stands for pairs, not positional--the
C:p adverb may be placed on any Hash objects to make it mean
pairs instead of values.)
@@ -435,7 +436,7 @@
Because named and positional arguments can be freely mixed, the
programmer always needs to disambiguate pairs literals from named
-arguments with parenthesis or quotes:
+arguments with parentheses or quotes:
# Named argument a
push @array, 1, 2, :ab;
@@ -453,7 +454,7 @@
fun( x = 1, x = 2 ); # @x := (1, 2)
fun( x = (1, 2), x = (3, 4) );# @x := (1, 2, 3, 4)
-Other sigils binds only to the Ilast argument with that name:
+Other sigil binds only to the Ilast argument with that name:
sub fun (Int $x) { ... }
f( x = 1, x = 2 );
Re: Patch for S06 (and also S03)
Sorry to patch the patch, but in -Other sigils binds only to the Ilast argument with that name: +Other sigil binds only to the Ilast argument with that name: the replacement makes no more sense than the original. Other sigils bind or Any other sigil binds would work here. Also, I believe the original of have an explicit declarator such as Csub or Cmethod; bare blocks and -pointy subs are never considered to be routines in that sense. To return +pointy blocks are never considered to be routines in that sense. To return from a block, use Cleave instead--see below. is correct. Pointy subs are consistently known as such, and I don't see any reason to rename them: the - symbol promotes a block (and optional arg list) into an anonymous sub, and the name reflects this. -- My invention can be exploited for a certain time as a scientific curiosity, but apart from that it has no commercial value whatsoever. Auguste Lumiere, on his and his brother's new invention of the motion- picture camera %% http://surreal.istic.org/ %% It's like a DEATH CIRCUS! signature.asc Description: Digital signature
Re: Patch for S06 (and also S03)
In a message dated Mon, 7 Aug 2006, Daniel Hulme writes:
Sorry to patch the patch, but in
-Other sigils binds only to the Ilast argument with that name:
+Other sigil binds only to the Ilast argument with that name:
the replacement makes no more sense than the original. Other sigils
bind or Any other sigil binds would work here.
My fault--I told agentzh++ fix 'other sigils binds' without specifying
what it should be fixed to ('other sigils bind').
Trey
[svn:perl6-synopsis] r10676 - doc/trunk/design/syn
Author: larry Date: Mon Aug 7 11:01:23 2006 New Revision: 10676 Modified: doc/trunk/design/syn/S02.pod Log: Clarified unspace ramifications. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Aug 7 11:01:23 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 10 Aug 2004 - Last Modified: 2 Aug 2006 + Last Modified: 7 Aug 2006 Number: 2 - Version: 57 + Version: 58 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -185,7 +185,10 @@ the line in any situation where a newline might confuse the parser, regardless of the currently installed parser. (Unless, of course, you override the unspace rule itself...) Although we say that the -unspace hides the whitespace from the parser, line numbers are still counted. +unspace hides the whitespace from the parser, line numbers are still counted +if the unspace contains one or more newlines. All other line-oriented +processing is suppressed, however--including pod directives and heredoc +boundaries. =item *
Re: Patch for S06 (and also S03)
On 8/8/06, Daniel Hulme [EMAIL PROTECTED] wrote: Sorry to patch the patch, but in -Other sigils binds only to the Ilast argument with that name: +Other sigil binds only to the Ilast argument with that name: the replacement makes no more sense than the original. Other sigils bind or Any other sigil binds would work here. Oh, thank you very much for pointing it out. I didn't even read the new sentence after I made the change. ;-) I should be more careful this next time. Also, I believe the original of have an explicit declarator such as Csub or Cmethod; bare blocks and -pointy subs are never considered to be routines in that sense. To return +pointy blocks are never considered to be routines in that sense. To return from a block, use Cleave instead--see below. is correct. Pointy subs are consistently known as such, and I don't see any reason to rename them: the - symbol promotes a block (and optional arg list) into an anonymous sub, and the name reflects this. I'm sorry disagree with this one since I am simply following Audrey's change on r10478: * S04, S06: Pointy sub and Pointy block was used interchangeably in the text, but as uri++ pointed out, it was very confusing as we also say that return escapes from subs but not blocks. Hence, rename all mention of pointy sub to pointy block. As Audrey said, the term pointy sub is very confusing. Thanks! Agent
Re: Patch for S06 (and also S03)
(Please ignore the previous mail. I was writing that in sleepy mode. Sorry.) On 8/8/06, Daniel Hulme [EMAIL PROTECTED] wrote: Sorry to patch the patch, but in -Other sigils binds only to the Ilast argument with that name: +Other sigil binds only to the Ilast argument with that name: the replacement makes no more sense than the original. Other sigils bind or Any other sigil binds would work here. Oh, thank you very much for correcting this. I didn't even read the sentence after I made the change. ;-) I should be more careful the next time. Also, I believe the original of have an explicit declarator such as Csub or Cmethod; bare blocks and -pointy subs are never considered to be routines in that sense. To return +pointy blocks are never considered to be routines in that sense. To return from a block, use Cleave instead--see below. is correct. Pointy subs are consistently known as such, and I don't see any reason to rename them: the - symbol promotes a block (and optional arg list) into an anonymous sub, and the name reflects this. I'm sorry that I disagree with this one since I am following Audrey's changes made as r10478: * S04, S06: Pointy sub and Pointy block was used interchangeably in the text, but as uri++ pointed out, it was very confusing as we also say that return escapes from subs but not blocks. Hence, rename all mention of pointy sub to pointy block. As Audrey said, the term pointy sub is very confusing in the context of using the return statement. I second her opinion here. :=) Thanks! Agent
Re: Patch for S06 (and also S03)
Oh, thank you very much for correcting this. I didn't even read the sentence after I made the change. ;-) I should be more careful the next time. Bah, you don't need to with an army of attentive proof-readers. I'm sorry that I disagree with this one since I am following Audrey's changes made as r10478: OK. I suppose that's what I get for going on holiday. -- Pray remember that Bacchus was a warrior, and that his armies had little fighting to do, because wherever he appeared he taught the cultivation of the vine to the grateful and submissive natives.-- J.B. Morton http://surreal.istic.org/ Peace through superior firepower. pgp74JNXsbkMn.pgp Description: PGP signature
[svn:perl6-synopsis] r10677 - doc/trunk/design/syn
Author: larry Date: Mon Aug 7 12:17:22 2006 New Revision: 10677 Modified: doc/trunk/design/syn/S02.pod Log: Also exempted initial # rule from unspaciness so that you can block comment even unspacey code. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Aug 7 12:17:22 2006 @@ -14,7 +14,7 @@ Date: 10 Aug 2004 Last Modified: 7 Aug 2006 Number: 2 - Version: 58 + Version: 59 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -186,7 +186,8 @@ regardless of the currently installed parser. (Unless, of course, you override the unspace rule itself...) Although we say that the unspace hides the whitespace from the parser, line numbers are still counted -if the unspace contains one or more newlines. All other line-oriented +if the unspace contains one or more newlines. Also, a C# in the first column +is always an end-of-line comment, as described above. All other line-oriented processing is suppressed, however--including pod directives and heredoc boundaries.
[svn:perl6-synopsis] r10678 - doc/trunk/design/syn
Author: larry Date: Mon Aug 7 12:38:13 2006 New Revision: 10678 Modified: doc/trunk/design/syn/S02.pod Log: Gah, would help if I actually thought about these things before committing... Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Aug 7 12:38:13 2006 @@ -14,7 +14,7 @@ Date: 10 Aug 2004 Last Modified: 7 Aug 2006 Number: 2 - Version: 59 + Version: 60 This document summarizes Apocalypse 2, which covers small-scale lexical items and typological issues. (These Synopses also contain @@ -185,11 +185,28 @@ the line in any situation where a newline might confuse the parser, regardless of the currently installed parser. (Unless, of course, you override the unspace rule itself...) Although we say that the -unspace hides the whitespace from the parser, line numbers are still counted -if the unspace contains one or more newlines. Also, a C# in the first column -is always an end-of-line comment, as described above. All other line-oriented -processing is suppressed, however--including pod directives and heredoc -boundaries. +unspace hides the whitespace from the parser, line numbers are still +counted if the unspace contains one or more newlines. A C# following +such a newline is always an end-of-line comment, as described above. +Since Pod chunks count as whitespace to the language, they are also +swallowed up by unspace. Heredoc boundaries are suppressed, however, +so you can split excessively long heredoc intro lines like this: + +ok(q:to'CODE', q:to'OUTPUT', \ +Here is a long description, \ # --more-- +todo(:parrøt0.42, :dötnet1.2)); + ... + CODE + ... + OUTPUT + +To the heredoc parser that just looks like: + +ok(q:to'CODE', q:to'OUTPUT', Here is a long description, todo(:parrøt0.42, :dötnet1.2)); + ... + CODE + ... + OUTPUT =item *
RE: [svn:perl6-synopsis] r10678 - doc/trunk/design/syn
You may interpolate a string into a package or variable name using ::($expr) where you'd ordinarily put a package or variable name. The string is allowed to contain additional instances of ::, which will be interpreted as package nesting. You may only interpolate entire names, since the construct starts with ::, and either ends immediately or is continued with another :: outside the curlies. What curlies? All I see is parens...
RE: [svn:perl6-synopsis] r10678 - doc/trunk/design/syn
Sorry, over-trimmage. That's in S02. -Original Message- From: Reed, Mark (TBS) Sent: Monday, August 07, 2006 4:28 PM To: '[EMAIL PROTECTED]'; 'perl6-language@perl.org' Subject: RE: [svn:perl6-synopsis] r10678 - doc/trunk/design/syn You may interpolate a string into a package or variable name using ::($expr) where you'd ordinarily put a package or variable name. The string is allowed to contain additional instances of ::, which will be interpreted as package nesting. You may only interpolate entire names, since the construct starts with ::, and either ends immediately or is continued with another :: outside the curlies. What curlies? All I see is parens...
[svn:perl6-synopsis] r10680 - doc/trunk/design/syn
Author: larry Date: Mon Aug 7 13:37:03 2006 New Revision: 10680 Modified: doc/trunk/design/syn/S02.pod Log: Interesting fossil discovered by Mark.Reed++. Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podMon Aug 7 13:37:03 2006 @@ -942,7 +942,7 @@ The string is allowed to contain additional instances of C::, which will be interpreted as package nesting. You may only interpolate entire names, since the construct starts with C::, and either ends -immediately or is continued with another C:: outside the curlies. +immediately or is continued with another C:: outside the parens. Most symbolic references are done with this notation: $foo = Bar;
RE: [svn:perl6-synopsis] r10680 - doc/trunk/design/syn
Log: Interesting fossil discovered by Mark.Reed++. Fossil, eh? Hm. Mark Indiana Reed, Documentational Archaeologist. I should get cards made up... Thanks for the fix...
Re: [svn:perl6-synopsis] r10679 - doc/trunk/design/syn
At 1:12 PM -0700 8/7/06, [EMAIL PROTECTED] wrote: Modified: doc/trunk/design/syn/S06.pod == @@ -1265,10 +1266,10 @@ :(\Any(Dog)) -and match a function taking a single value of type Dog. +and match a function taking a single parameter of type Dog. Typo: Shouldn't that last line better say either having a single parameter or taking a single argument? -- Darren Duncan
weak roles
The CPAN has many reinvented wheels. This happened since we have so
many authors (== opinions) over so many years.
For example, we have Mail::Message to Email::Simple, to
Mail::Internet to They all do the same thing differently.
Then there is Email::Abstract, which provides a simplified API for
all of these together, so that modules like Mail::Thread can work
with either.
With the introduction of roles, supposedly this is going to be less
of a problem. Email::Abstract would ideally be a role that the
organically grown message abstracting classes just 'do'.
However, suppose that Email::Abstract itself would be reinvented.
The message modules now have to choose between either
Email::Abstract or Email::Abstract::Better as the one role to do
(since they probably conflict), or it will have to do weird magic to
disambiguate in a context sensitive way.
I think a nice idea to work around this would be to introduce weak
roles, that are lexically scoped.
The way it could work is a bit like this:
class Mail::TheOneTrueWay {
does Mail::SomeAPI is weak {
method header; # this method has different semantics for
# each role. It would normally conflict.
}
does Mail::SomeOtherAPI is weak {
method header;
}
method body; # this method is shared between the two roles
}
Then, when a module is expecting a message object it declares the
role it wants this object to do for this scope:
sub analyze_mail ( Mail::SomeAPI $message ) {
$message.foo; # unambiguous
}
This way coercion can be avoided, which means that keeping mutable
coerced objects synchronized is no longer necessary, thus
simplifying the code path and encouraging even more
pluggability/polymorphism.
I'm not sure on the behavior of $obj.does outside of the role
strenghning scope.
I am pretty sure that this should be purely lexical, and not
dynamic, even for .does (if it's true on the inside).
Perhaps an invokation of an ambiguous method is an error for the
caller ($object responds to N flavours of the header method, you
must explicitly say which flavour you prefer right now).
Delegates are another way around this but let's face it:
1. they're not as popular as they should be
2. they're more classes to write
3. they're harder to use
Consequentially we have fairly few delegate based APIs for these
problems (Email:Abstract is the only one I know).
--
Yuval Kogman [EMAIL PROTECTED]
http://nothingmuch.woobling.org 0xEBD27418
pgpsRApD6diiG.pgp
Description: PGP signature
