Google Welcome to the home page for Perl 6 (Perl 6 Wiki)
FYI: Just noticed that the increasingly-populated Perl 6 Wiki was recently
crawled by Google. ... Unfortunately the Wiki doesn't turn up anywhere near
the top of simple perl6 and Perl 6 Google searches yet. ... Someday soon,
hopefully
Below are Google results from doing local site search for perl using
site:rakudo.org/perl6 perl (without quotes).
Perl 6 - Perl 6
Perl 6 is the insanely great next version of the Perl programming language.
... For our regular visitors, current Perl 6 news is provided below. ...
rakudo.org/perl6 - 27k - Sep 10, 2006 - Cached - Similar pages
Learn About Perl 6 - Perl 6
This page is for general resources to learn about Perl 6. ... Damian Conway
(2003): The Perl 6 design process is about keeping what works in Perl 5, ...
rakudo.org/perl6/index.cgi?learn_about_perl_6 - 30k - Sep 10, 2006 - Cached
- Similar pages
Download Perl 6 - Perl 6
If you plan to contribute to Perl 6, you can see about getting a free
account ... Perl Community Development Server. There a fresh version of Pugs
is built ...
rakudo.org/perl6/index.cgi?download_perl_6 - 26k - Sep 10, 2006 - Cached -
Similar pages
Glossary of Perl 6 Terms and Jargon - Perl 6
However Perl 6 to Perl 5 bridges will eventually make all of CPAN look like
... #perl6 is the Perl 6 IRC channel. Information for accessing the logs
and ...
rakudo.org/perl6/index.cgi?glossary_of_perl_6_terms_and_jargon - 28k - Sep
10, 2006 - Cached - Similar pages
Perl 6 for Perl 5 - Perl 6
Perl 6 features are also coming to Perl 5 in other ways. As described below,
a number of Perl 5 modules already implement some Perl 6 features, ...
rakudo.org/perl6/index.cgi?perl_6_for_perl_5 - 23k - Cached - Similar pages
Getting Involved - Perl 6
You might also be interested to Start Your Own Perl 6 Module, ... This plan
is still current AFAIK: Perl 6 developers are refactoring relevant ...
rakudo.org/perl6/index.cgi?getting_involved - 27k - Sep 10, 2006 - Cached -
Similar pages
Documentation - Perl 6
Official Perl 6 Documentation (Which means, documentation that is officially
bundled ... The rapidly growing Perl 6 test base is another {very important,
...
rakudo.org/perl6/index.cgi?documentation - 27k - Sep 10, 2006 - Cached -
Similar pages
Mail Lists, IRC, Archives - Perl 6
Perl 6 Mailing Lists The currently active Perl 6 mailing lists are at ...
Perl 6 IRC IRC channels (and their archives) are a major source of useful
...
rakudo.org/perl6/index.cgi?mail_lists_irc_archives - 28k - Sep 10, 2006 -
Cached - Similar pages
Etc.,
Etc.,
Etc.
Best regards,
Conrad Schneiker
www.AthenaLab.com
Nano-electron-beam and micro-neutron-beam technology.
Check out the new Perl 6 Workplace Wiki:
http://rakudo.org/perl6
single named param
I was writing tests for signatures and came across this ambiguity: :(:$x) Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: single named param
On Tue, Sep 12, 2006 at 06:46:50PM +0800, Audrey Tang wrote: Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? A default invocant prolly doesn't make sense there... There's nothing to default to. :-) What invocant is constructed in this signature then? method foo ($just_a_named_param) Is the signature for foo really the same as that of bar? sub bar ($just_a_named_param) I was sort of assuming you could tell by a signature if it was for a method or a sub. -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
Re: [svn:perl6-synopsis] r11965 - doc/trunk/design/syn
larry schreef: +Likewise, from the fact that list context flattens inner arrays and +lists, it follows that a reduced assignment does no special syntactic +dwimmery, and hence only scalar assigments are supported. Therefore + +[=] $x, @y, $z, 0 +[+=] $x, @y, $z, 1 + +are equivalent to + +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 I assume that [=] $x, @y is equivalent to $x = @y[0] = @y[1] = @y[2] ... @y[-2] = y[-1] then. Or is a scalar required at the end? -- Affijn, Ruud Gewoon is een tijger.
Libraries, dynpmc and Visual C++
This is on trunk, revision 14585, using Windows XP and Visual C++.
I have GDBM available as gdbm.lib which is successfully tested for in
config/auto/gdbm.pm.
Determining if your platform supports gdbm...
...
gdbm is working.
(yes) .done.
For some reason this library list is rewritten in tools/build/dynpmc.pl
if ($^O eq 'MSWin32') {
my %newlibs = ();
$newlibs{lib$_} = $libs{$_} for keys %libs;
%libs = %newlibs;
}
Leading to the following error message while linking gdbmhash.dll.
LINK : fatal error LNK1104: cannot open file 'libgdbm.lib'
Looking at the tests in config/auto/gdbm.pm I'd guess adding the lib
prefix is done for GCC on Windows. If so, the condition should probably
read something like $^O eq 'MSWin32' $CC =~ /^gcc/i. That way the
build seems fine again on Windows XP and Visual C++.
Ron
Re: Libraries, dynpmc and Visual C++
Applied as r14586.
Jerry Gay was having a similar issue yesterday.
Anyone with gcc on win32 care to verify it works for them still?
Some of this duplicate (or disparate) build logic will hopefully go
away as the build system gets cleaned up in the coming weeks.
On Sep 12, 2006, at 12:27 PM, Ron Blaschke wrote:
This is on trunk, revision 14585, using Windows XP and Visual C++.
I have GDBM available as gdbm.lib which is successfully tested
for in
config/auto/gdbm.pm.
Determining if your platform supports gdbm...
...
gdbm is working.
(yes) .done.
For some reason this library list is rewritten in tools/build/
dynpmc.pl
if ($^O eq 'MSWin32') {
my %newlibs = ();
$newlibs{lib$_} = $libs{$_} for keys %libs;
%libs = %newlibs;
}
Leading to the following error message while linking gdbmhash.dll.
LINK : fatal error LNK1104: cannot open file 'libgdbm.lib'
Looking at the tests in config/auto/gdbm.pm I'd guess adding the lib
prefix is done for GCC on Windows. If so, the condition should
probably
read something like $^O eq 'MSWin32' $CC =~ /^gcc/i. That way
the
build seems fine again on Windows XP and Visual C++.
Ron
--
Will Coke Coleda
[EMAIL PROTECTED]
Re: Libraries, dynpmc and Visual C++
Will Coleda wrote: Applied as r14586. Jerry Gay was having a similar issue yesterday. Anyone with gcc on win32 care to verify it works for them still? Some of this duplicate (or disparate) build logic will hopefully go away as the build system gets cleaned up in the coming weeks. Thanks! Parrot smokes well on Windows XP and Visual C++ again. 5488 OK from 5499 tests (99.80% ok) Ron
sub ($self: $foo ) (was: Re: single named param)
Larry Wall wrote: I'm trying to decide if sub ($self: $just_a_named_param) can meaningfully put anything into $self. It seems doubtful, and it should probably be submethod ($self: $just_a_named_param) I agree. If sub ($self: $foo) works than it reduces privacy, since someone could call a sub like externally, when it wasn't intended. Mark
Re: [svn:perl6-synopsis] r11965 - doc/trunk/design/syn
On Tue, Sep 12, 2006 at 06:16:26PM +0200, Dr.Ruud wrote: : larry schreef: : : +Likewise, from the fact that list context flattens inner arrays and : +lists, it follows that a reduced assignment does no special syntactic : +dwimmery, and hence only scalar assigments are supported. Therefore : + : +[=] $x, @y, $z, 0 : +[+=] $x, @y, $z, 1 : + : +are equivalent to : + : +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 : +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 : : I assume that : : [=] $x, @y : : is equivalent to : : $x = @y[0] = @y[1] = @y[2] ... @y[-2] = y[-1] : : then. Yes. : Or is a scalar required at the end? Yes, but @y[-1] is a perfectly fine scalar. Larry
Re: the CGI.pm in Perl 6
Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. But then this new module cannot profit of the popularity of the name CGI.pm and many people will say Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface. I'll use (python|ruby( on rails)?|.+). That would be sad. IMHO even Perl people like me will think Ah, Perl6 web development is stuck at the 10 years old Perl5 CGI.pm interface just *because* of the name, regardless of a changed internal api. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. The name CGI smells like, erm, yes, C...G...I. If RoR would have sold itself with CGI in its name, it hadn't been that successful. In mankind's history, everything *not* named CGI had a chance to success, even PHP. It will be impossible to resurrect a hype around the word CGI. Because of the word. Not the api. IMHO. Of course. :-) GreetinX Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
[svn:perl6-synopsis] r11969 - doc/trunk/design/syn
Author: larry
Date: Tue Sep 12 11:07:01 2006
New Revision: 11969
Modified:
doc/trunk/design/syn/S03.pod
Log:
New X operator and metaoperator.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Sep 12 11:07:01 2006
@@ -14,7 +14,7 @@
Date: 8 Mar 2004
Last Modified: 12 Sep 2006
Number: 3
- Version: 58
+ Version: 59
=head1 Changes to Perl 5 operators
@@ -639,7 +639,7 @@
operators yourself. Similarly, the carets that exclude the endpoints
on ranges are there by convention only.
-In contrast to that, Perl 6 has four standard metaoperators for
+In contrast to that, Perl 6 has five standard metaoperators for
turning a given existing operator into a related operator that is
more powerful (or at least differently powerful). These differ from a
mere naming convention in that Perl automatically generates these new
@@ -801,7 +801,7 @@
=head2 Reduction operators
-The final metaoperator in Perl 6 is the reduction operator. Any
+The fourth metaoperator in Perl 6 is the reduction operator. Any
infix operator (except for non-associating operators)
can be surrounded by square brackets in term position to
create a list operator that reduces using that operation:
@@ -1025,6 +1025,52 @@
mean the normal reduction of C infix:\x operator, not the triangular
reduction of C infix:x . This is deemed to be an insignificant problem.
+=head1 Cross operators
+
+The final metaoperator is the CX metaoperator. It applies the
+modified operator across all permutations of its list arguments. All
+CX operators are of list infix precedence, and are list associative.
+
+The bare form of CX is considered an operator in its own right.
+Saying:
+
+a b X 1,2 X x y
+
+produces
+
+['a', 1, 'x'],
+['a', 1, 'y'],
+['a', 2, 'x'],
+['a', 2, 'y'],
+['b', 1, 'x'],
+['b', 1, 'y'],
+['b', 2, 'x'],
+['b', 2, 'y']
+
+The string concatenating form is:
+
+a b X~ 1 2 # 'a1', 'a2', 'b1', 'b2'
+
+As a metaoperator, CX~ operator desugars to something like:
+
+[~]«( a b X 1 2 ) # 'a1', 'a2', 'b1', 'b2'
+
+Any existing, non-mutating infix operator may be used after the CX.
+
+1,2 X* 3,4 # 3,4,6,8
+
+(Note that C == and C == are considered mutating, as well as
+all assignment operators.)
+
+If the underlying operator is non-associating, so is the metaoperator:
+
+@a Xcmp @b Xcmp @c # ILLEGAL
+@a Xeq @b Xeq @c # ok
+
+Unlike bare CX, the CX, form flattens much like C[,] does.
+
+a b X, 1 2 # 'a', '1', 'a', '2', 'b', '1', 'b', '2'
+
=head1 Junctive operators
C|, C, and C^ are no longer bitwise operators (see
@@ -1401,6 +1447,18 @@
@foo := [[1,2,3],[4,5,6]]; say cat([;] @foo); # 1,2,3,4,5,6
+=head1 Crossing arrays
+
+In contrast to the zip operator, the CX operator returns all the
+permutations of its sublists. Hence you may say:
+
+a b X 1 2
+
+and you end up with
+
+['a', '1'], ['a', '2'], ['b', '1'], ['b', '2']
+
+It is really a variant of the CX metaoperator mentioned earlier.
=head1 Minimal whitespace DWIMmery
Whitespace is no longer allowed before the opening bracket of an array
@@ -1481,7 +1539,7 @@
!!! ... ???
[+] [*] [] [,] [\+] [\*] etc.
(also = as list assignment)
-list infix ¥ == ==
+list infix ¥ == == X X~ X* Xeqv etc.
loose and and
loose oror xor err
expr terminator ; {} as control block, statement modifiers
[svn:perl6-synopsis] r11971 - doc/trunk/design/syn
Author: larry Date: Tue Sep 12 11:20:04 2006 New Revision: 11971 Modified: doc/trunk/design/syn/S03.pod Log: Further clarifications and fixups. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Sep 12 11:20:04 2006 @@ -14,7 +14,7 @@ Date: 8 Mar 2004 Last Modified: 12 Sep 2006 Number: 3 - Version: 59 + Version: 60 =head1 Changes to Perl 5 operators @@ -982,7 +982,7 @@ Likewise, from the fact that list context flattens inner arrays and lists, it follows that a reduced assignment does no special syntactic -dwimmery, and hence only scalar assigments are supported. Therefore +dwimmery, and hence only scalar assignments are supported. Therefore [=] $x, @y, $z, 0 [+=] $x, @y, $z, 1 @@ -1067,10 +1067,17 @@ @a Xcmp @b Xcmp @c # ILLEGAL @a Xeq @b Xeq @c # ok +In fact, though the CX operators are all list associative +syntactically, the underlying operator is always applied with its +own associativity. + Unlike bare CX, the CX, form flattens much like C[,] does. a b X, 1 2 # 'a', '1', 'a', '2', 'b', '1', 'b', '2' +Note that only the first term of an CX operator may reasonably be +an infinite list. + =head1 Junctive operators C|, C, and C^ are no longer bitwise operators (see @@ -1183,7 +1190,7 @@ my ($b, $c); # okay my $b, $c; # wrong: Use of undeclared variable: $c -Types occuring between the declarator and the signature are distributed into +Types occurring between the declarator and the signature are distributed into each variable: my Dog ($b, $c); @@ -1459,6 +1466,7 @@ ['a', '1'], ['a', '2'], ['b', '1'], ['b', '2'] It is really a variant of the CX metaoperator mentioned earlier. + =head1 Minimal whitespace DWIMmery Whitespace is no longer allowed before the opening bracket of an array
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On Mon, Sep 11, 2006 at 13:31:55 -0700, Michael Snoyman wrote: I agree completely. In that vein, I think that one thing a lot of web developers would like to have available more easily would be session management. In PHP it's as simple as $_SESSION['key'] = 'value'. I understand that CGI.pm is a fundemantally different concept from PHP and that this can't be completely taken care of by the module. Still, if something could be written in, I think it would make many people's lives simpler. Please... no... There are *so* many ways to do session handling that lugging them all into CGI.pm will just make a mess. It'd work much better as mixin plugins of some sort. I'd be happy to discuss my conclusions from redesigning the Catalyst session handling, if you like. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpVLxZTi14RK.pgp Description: PGP signature
Web.pm or something (Re: the CGI.pm in Perl 6)
At 3:21 PM +0200 9/12/06, Thomas Wittek wrote: So I think that there should be a (well designed) module for those lower level (donkeywork) tasks and only for those (so definitely no HTML-generation...). I strongly suggest that if we're going to do things this way, which sounds like a good idea, then the new and well designed lower level module should NOT be named CGI.pm ... if nothing else, it is because that name sends the wrong message in today's age. The word CGI generally speaks to an old, weak, and relatively inefficient technology ... modern proper stuff does not spin off a separate process for each server request; it reuses an existing server ala mod_perl. But this module in question should provide a low level layer that one can use without changes regardless of whether the script is running in CGI mode, or under mod_perl or ISAPI or as a pure-Perl server or on the command-line. As for Web.pm, that may work better, but are there any reasonably conceivable uses outside HTTP/HTTPS stuff that may invalidate the name? Either way, I agree; no HTML generation in this core module. Just management of our server-side view of web client input and output. In fact, it may borrow a few pages of design from LWP if applicable? -- Darren Duncan
Re: the CGI.pm in Perl 6
Steffen Schwigon schrieb: Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. I would strongly expect the CGI module to do the same as it did for the last 200 years and create another name for any new school web development. Catalyst, Jifty, Acme, Acyou, SillyIdol, WhatEver. So we might agree ;) Catalysy, Jifty [..] are all higher level complete frameworks. I used CGI.pm for rather lower level tasks (POST/GET-parsing, HTTP redirects, ...) than as a foundation to build complete applications (where the higher level framework come in). So I think that there should be a (well designed) module for those lower level (donkeywork) tasks and only for those (so definitely no HTML-generation...). Other frameworks (or simple CGI-scripts or even a backwards compatible CGI.pm) could be built upon this foundation. -Thomas
Re: the CGI.pm in Perl 6
Thomas Wittek [EMAIL PROTECTED] writes: An other acceptable solution would be to create a backwards compatible P6 CGI.pm and create a new Web.pm with an all new interface, like Mark suggested. My 0.02 ₪: CGI.pm will be better off redesigned and cleaned up, and for those wanting compatibility a module called CGI5.pm can be written. It will probably be very popular, like p5 regexes ...
Re: String.to_int() vs. opcode
jerry gay wrote: but Csay $I0 does *not* work. i find that annoying. either make the syntax for methods different than ops (eg C$S0.say()) or make Csay an opcode, or dodge the syntax issue and make Csay a method on all register types. forcing me to convert the int to a string in order to auto-print a newline instead of printing the int and the newline separately saves me no code. having an op that's named the same as a parrot op but is limited to one register type is confusing. Agreed. On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote: I do think pulling too hard at this thread might require a closer look at what's current in src/pmc/ vs. src/*.c vs src/ops/ (where's there's smoke...): a lot of the current state has been a result of organic (rather than planned) growth. Overall, this sounds like an excellent addition to the coding standards, and an excellent task for the cage cleaners. Allison
Re: [perl #40316] [NEW] opcodes not tested script
On 9/12/06, Leopold Toetsch via RT [EMAIL PROTECTED] wrote: Thanks, applied - r14594. * moved to tools/dev directory * be sure to 'make testr' before looking at script results *but* do you have any hint on how to get this? * disassemble did hang here during that - I killed it after it accumulate 1.7 GB of memory. on my x86_64 it simple segfaults *a lot* when disassembling all @pmcs * there might be some disassemble bug lurking somewhere, which doesn't make me wonder at all, because it's heavily untested. leo -- Will work for bandwidth
Re: [svn:perl6-synopsis] r11971 - doc/trunk/design/syn
+Note that only the first term of an CX operator may reasonably be +an infinite list. Now all we need is a variant that does the diagonal order and we'll be home and dry. 'a'..* diagX 1..* - ['a', 1], ['a', 2], ['b', 1], ['a', 3], ['b', 2], ['c', 1], ['a', 4], ['b', 3], ['c', 2], ['d', 1], and so on. -- Every program eventually reaches a point where it becomes harder to make a simple change than to rewrite the program from scratch. Unfortunately, when this point is reached, it is far too late to consider rewriting it. http://surreal.istic.org/ They knew about the decepticons. pgpNeSV0WxqBg.pgp Description: PGP signature
Re: [svn:perl6-synopsis] r11965 - doc/trunk/design/syn
Larry Wall schreef: Dr.Ruud: larry: +Likewise, from the fact that list context flattens inner arrays and +lists, it follows that a reduced assignment does no special syntactic +dwimmery, and hence only scalar assigments are supported. Therefore + +[=] $x, @y, $z, 0 +[+=] $x, @y, $z, 1 + +are equivalent to + +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 I assume that [=] $x, @y is equivalent to $x = @y[0] = @y[1] = @y[2] ... @y[-2] = @y[-1][_edited_] then. Yes. Or is a scalar required at the end? Yes, but @y[-1] is a perfectly fine scalar. Yes, but I meant it more at a 'source-filter' level. Suppose that you need to set everything to @y[0], I think you can code [=] $x, @y, @y[0]# looks clean, but does extra, # but maybe in an efficient order [=] $x, @y[1 .. *], @y[0] # hand-optimized? [=] $x, @y.reverse # or does .reverse copy? [=] $x, @y[reverse 0 .. *] # hi-brow? and what not. (Pardon my French.) -- Affijn, Ruud Gewoon is een tijger.
Re: META vs meta
Larry Wall wrote: : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta. .META is more correct at the moment. Does making it all upper caps really help? It's still a pollution of the method space, any way that you look at it... What about this form: #meta $o.?meta #ref $o.?type #var $o.?var #id $o.?id Only that I'm thinking of renaming all the meta-ish methods to use interrogative pronouns: .META - .HOW .SKID - .WHO .PKG - .WHAT .VAR - .WHERE Oo-er. Well, you're the linguist ;) Sam.
Re: single named param
在 Sep 12, 2006 6:59 PM 時，Gaal Yahas 寫到： What invocant is constructed in this signature then? method foo ($just_a_named_param) Is the signature for foo really the same as that of bar? sub bar ($just_a_named_param) As Larry said, they shouldn't be the same; the first one is foo.signature === :($ : $just_a_named_param); The second one is: bar.signature === :($just_a_named_param); I was sort of assuming you could tell by a signature if it was for a method or a sub. That's correct; the method keyword augments the signature with an unnamed $ invocant if it's not explicitly specified. (In Pugs.Val.Code terms, that's nullID for both the p_label slot and (v_name . p_variable).) Cheers, Audrey
Re: single named param
2006/9/12, Gaal Yahas [EMAIL PROTECTED]: Does this mean a single named parameter called $x, or a default invocant and a single required positional named $x? A default invocant prolly doesn't make sense there... There's nothing to default to. :-) Audrey
Re: single named param
On Tue, Sep 12, 2006 at 01:59:23PM +0300, Gaal Yahas wrote: : On Tue, Sep 12, 2006 at 06:46:50PM +0800, Audrey Tang wrote: : Does this mean a single named parameter called $x, or a default invocant : and a single required positional named $x? : : A default invocant prolly doesn't make sense there... There's : nothing to default to. :-) : : What invocant is constructed in this signature then? : : method foo ($just_a_named_param) : : Is the signature for foo really the same as that of bar? : :sub bar ($just_a_named_param) Maybe methods and submethods turn method foo ($just_a_named_param) into method foo ($ : $just_a_named_param) Since we regularized invocants, there's much less need for an empty invocant, so maybe the $ is required there if you put the :. If so, we should probably explicitly say that there are no variables of the form $:, $;, or $,, so those will always be taken as $ :, $ ;, and $ , respectively. At least within signatures. In any case, prefix ':' is not an operator. In :(:$foo) the :$ starts a token, so you'd have to put space between to mean :(: $foo). : I was sort of assuming you could tell by a signature if it was for a : method or a sub. I'm trying to decide if sub ($self: $just_a_named_param) can meaningfully put anything into $self. It seems doubtful, and it should probably be submethod ($self: $just_a_named_param) So for the jet-lagged moment I think your assumption is valid. I might jet-delag at any moment, however... Larry
[svn:perl6-synopsis] r11965 - doc/trunk/design/syn
Author: larry Date: Tue Sep 12 07:51:14 2006 New Revision: 11965 Modified: doc/trunk/design/syn/S03.pod Log: Allow [=] and [+=]. Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podTue Sep 12 07:51:14 2006 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 8 Mar 2004 - Last Modified: 4 Sep 2006 + Last Modified: 12 Sep 2006 Number: 3 - Version: 57 + Version: 58 =head1 Changes to Perl 5 operators @@ -802,8 +802,8 @@ =head2 Reduction operators The final metaoperator in Perl 6 is the reduction operator. Any -infix operator (except for non-associating operators and assignment -operators) can be surrounded by square brackets in term position to +infix operator (except for non-associating operators) +can be surrounded by square brackets in term position to create a list operator that reduces using that operation: [+] 1, 2, 3; # 1 + 2 + 3 = 6 @@ -980,6 +980,26 @@ @args = (\%a,'foo','bar'); $x = [dehash] @args; +Likewise, from the fact that list context flattens inner arrays and +lists, it follows that a reduced assignment does no special syntactic +dwimmery, and hence only scalar assigments are supported. Therefore + +[=] $x, @y, $z, 0 +[+=] $x, @y, $z, 1 + +are equivalent to + +$x = @y[0] = @y[1] = @y[2] ... @y[-1] = $z = 0 +$x += @y[0] += @y[1] += @y[2] ... @y[-1] += $z += 1 + +rather than + +$x = @y = $z = 0; +$x += @y += $z += 1; + +(And, in fact, the latter are already easy to express anyway, +and more obviously nonsensical.) + A reduce operator returns only a scalar result regardless of context. (Even C[,] returns a single CCapture object which is then spliced into the outer argument list.) To return all intermediate results,
Re: META vs meta
On Wed, Sep 13, 2006 at 10:20:31AM +1200, Sam Vilain wrote: Larry Wall wrote: : There is currently a mismatch between S12 and Pugs. The former specifies $obj.META, the latter has implemented $obj.meta. .META is more correct at the moment. Does making it all upper caps really help? It's still a pollution of the method space, any way that you look at it... Yeah but perl has already has a cultural claim on ALLCAPS thingys. So, yes, it does help. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
[svn:perl6-synopsis] r11974 - doc/trunk/design/syn
Author: audreyt
Date: Tue Sep 12 19:35:59 2006
New Revision: 11974
Modified:
doc/trunk/design/syn/S03.pod
Log:
* S03: Typographical and stylistic cleanups.
Also, clarify that identity values of reduce hyperoperators
is more logically defined by the way of a multi variant of zero
arity, rather than specifying it inside the proto itself.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Sep 12 19:35:59 2006
@@ -12,9 +12,9 @@
Maintainer: Larry Wall [EMAIL PROTECTED]
Date: 8 Mar 2004
- Last Modified: 12 Sep 2006
+ Last Modified: 13 Sep 2006
Number: 3
- Version: 60
+ Version: 61
=head1 Changes to Perl 5 operators
@@ -50,7 +50,7 @@
a boolean (CBool) context, and the C[,] list operator imposes
a function-arguments (CCapture) context on its arguments.
Unary sigils impose the container context implied by their sigil.
-As with Perl 5, however, C$$foo[bar] parses as C$($foo)[bar],
+As with Perl 5, however, C$$foo[bar] parses as C( $($foo) )[bar],
so you need C$($foo[bar]) to mean the other way.
=item * Bitwise operators get a data type prefix: C+, C~, or C?.
@@ -543,7 +543,7 @@
$_ $xType of Match ImpliedMatching Code
== = ==
-Any Code:($) scalar sub truth match if $x($_)
+Any Code:($) scalar sub truth match if $x($_)
HashHash hash keys identical match if $_.keys.sort »eq«
$x.keys.sort
Hashany(Hash) hash key intersectionmatch if $_{any(Hash.keys)}
HashArray hash value slice truth match if $_{any(@$x)}
@@ -602,7 +602,7 @@
you can't write:
given $boolean {
- when True {...}
+ when True {...}
when False {...}
}
@@ -610,7 +610,7 @@
given $boolean {
when .true {...}
- when .not {...}
+ when .not {...}
}
Better, just use an Cif statement.
@@ -648,7 +648,7 @@
metaoperations--their semantics are supposed to be self-evident by
the transformation of the base operator.
-Note: spaces are never allowed between any metaoperator and the
+Note: Spaces are never allowed between any metaoperator and the
operator it's modifying, because all operators including modified
ones have to be recognized by the Longest-Token Rule, which disallows
spaces within a token.
@@ -672,7 +672,7 @@
of any assignment operators is forced to be the same as that of
ordinary assignment.
-=head2 Negated relational operators.
+=head2 Negated relational operators
Any infix relational operator may be transformed into its negative
by prefixing with C!. A couple of these have traditional shortcuts:
@@ -720,7 +720,7 @@
In fact, this is the Ionly form that will work for an unordered type
such as a CBag:
- Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) ~~ Bag(1,2,2,7,7,8)
+ Bag(3,8,2,9,3,8) - 1; # Bag(2,7,1,8,2,7) === Bag(1,2,2,7,7,8)
When using a unary operator, only put the hyper on the side of the
single operand:
@@ -870,11 +870,15 @@
multi prefix:[foo] (Int $x) { 42 }
multi prefix:[foo] (Str $x) { fail Can't foo a single Str }
-However, the zero argument case must of necessity be handled by the
-proto version, since there is no type information to dispatch on.
-Operators that wish to specify an identity value should do so by
-specifying the proto listop. Among the builtin operators, C[+]()
-returns 0 and C[*]() returns 1, for instance.
+However, the zero argument case cannot be defined this way, since there
+is no type information to dispatch on. Operators that wish to specify an
+identity value should do so by specifying a multi variant that takes zero
+arguments:
+
+multi prefix:[foo] () { 0 }
+
+Among the builtin operators, C[+]() returns 0 and C[*]() returns 1,
+for instance.
By default, if there is one argument, the built-in reduce operators
return that one argument. However, this default doesn't make sense
[svn:perl6-synopsis] r11975 - doc/trunk/design/syn
Author: larry
Date: Tue Sep 12 21:09:33 2006
New Revision: 11975
Modified:
doc/trunk/design/syn/S03.pod
Log:
tweaks to crossop syntax
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Sep 12 21:09:33 2006
@@ -1031,14 +1031,22 @@
=head1 Cross operators
-The final metaoperator is the CX metaoperator. It applies the
+The final metaoperator is the cross metaoperator. It is formed syntactically
+by placing an infix operator between two CX characters. It applies the
modified operator across all permutations of its list arguments. All
-CX operators are of list infix precedence, and are list associative.
+cross operators are of list infix precedence, and are list associative.
-The bare form of CX is considered an operator in its own right.
-Saying:
+The string concatenating form is:
+
+a b X~X 1 2 # 'a1', 'a2', 'b1', 'b2'
+
+The CX~X operator desugars to something like:
+
+[~]«( a b X 1 2 ) # 'a1', 'a2', 'b1', 'b2'
-a b X 1,2 X x y
+The list concatenating form
+
+a b X,X 1,2 X,X x y
produces
@@ -1051,33 +1059,25 @@
['b', 2, 'x'],
['b', 2, 'y']
-The string concatenating form is:
-
-a b X~ 1 2 # 'a1', 'a2', 'b1', 'b2'
-
-As a metaoperator, CX~ operator desugars to something like:
-
-[~]«( a b X 1 2 ) # 'a1', 'a2', 'b1', 'b2'
+The string and list forms are common enough to have shortcuts, CX
+and CXX respectively. See below.
-Any existing, non-mutating infix operator may be used after the CX.
+For the general form, any existing, non-mutating infix operator
+may be used.
-1,2 X* 3,4 # 3,4,6,8
+1,2 X*X 3,4 # 3,4,6,8
(Note that C == and C == are considered mutating, as well as
all assignment operators.)
If the underlying operator is non-associating, so is the metaoperator:
-@a Xcmp @b Xcmp @c # ILLEGAL
-@a Xeq @b Xeq @c # ok
+@a XcmpX @b XcmpX @c # ILLEGAL
+@a XeqX @b XeqX @c # ok
In fact, though the CX operators are all list associative
syntactically, the underlying operator is always applied with its
-own associativity.
-
-Unlike bare CX, the CX, form flattens much like C[,] does.
-
-a b X, 1 2 # 'a', '1', 'a', '2', 'b', '1', 'b', '2'
+own associativity, just as the corresponding reduce operator would do.
Note that only the first term of an CX operator may reasonably be
an infinite list.
@@ -1460,16 +1460,24 @@
=head1 Crossing arrays
-In contrast to the zip operator, the CX operator returns all the
+In contrast to the zip operator, the CXX operator returns all the
permutations of its sublists. Hence you may say:
-a b X 1 2
+a b XX 1 2
and you end up with
['a', '1'], ['a', '2'], ['b', '1'], ['b', '2']
-It is really a variant of the CX metaoperator mentioned earlier.
+The CX variant crosses the arrays but concatenates strings:
+
+a b X 1 2
+
+produces
+
+'a1', 'a2', 'b1', 'b2'
+
+The resemblance to Cx and Cxx is not entirely accidental.
=head1 Minimal whitespace DWIMmery
@@ -1551,7 +1559,7 @@
!!! ... ???
[+] [*] [] [,] [\+] [\*] etc.
(also = as list assignment)
-list infix ¥ == == X X~ X* Xeqv etc.
+list infix ¥ == == X XX X~X X*X XeqvX etc.
loose and and
loose oror xor err
expr terminator ; {} as control block, statement modifiers
Re: [svn:perl6-synopsis] r11975 - doc/trunk/design/syn
svn log, speaking on larry's behalf (): +The string concatenating form is: + +a b X~X 1 2 # 'a1', 'a2', 'b1', 'b2' + +The CX~X operator desugars to something like: + +[~]«( a b X 1 2 ) # 'a1', 'a2', 'b1', 'b2' ...and later... +The CX variant crosses the arrays but concatenates strings: + +a b X 1 2 + +produces + +'a1', 'a2', 'b1', 'b2' If the CX variant already concatenates strings, why is it done explicitly in the desugaring of CX~X? Probably not what you intended. Kindly, // masak
