Big update to the Perl 6 Workplace Wiki
# FYI. The note below was originally posted on perl.perl6.users. # Thought some folks here should also be interested in this. # # Background: # # http://www.nntp.perl.org/group/perl.perl6.internals/34764 # Announcing the Perl 6 and Parrot wiki workspaces # # http://www.nntp.perl.org/group/perl.perl6.users/357 # From: Andy Lester [mailto:andy[at]petdance.com] # # I'm working with Ask about doing something # at perl.org in the next week or two. Ive just finished a big update to the Perl 6 Workplace Wiki. It got big enough that I started splitting it into subsidiary pages. The main page is still pretty long, but Ive added a table of contents to make it easier to find things on it. Please give it a look, and please add useful stuff to it. http://rakudo.org/perl6/index.cgi # Main page. http://rakudo.org/perl6/index.cgi#the_long_perl_6_super_feature_list http://rakudo.org/perl6/index.cgi?glossary_of_perl_6_terms_and_jargon PS: Once again, I want to thank the folks at perl.net.au for doing the original wikifying of my Perl 6 Users FAQ on their Perl 6 Wiki a few months ago. Being able to cut and paste most of the pre-formatted content with links already in place (with very minimal post-copy tweaking) saved a tremendous amount of time. 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
Re: Naming the method form of s///
Audrey Tang skribis 2006-09-01 19:10 (+0800): Because of the awkward syntax that goes with a method: two parens, four delimiters, comma[s]?. .s(/bar/, baz); # 20 keypresses on a US keyboard Minor nit, but: .s: /bar/,'baz'; # 17 keypresses... And since it's something used a lot in expressions, you wouldn't use the parenless form of the method call much. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Nested statement modifiers.
Paul == Paul Seamons [EMAIL PROTECTED] writes: Paul I don't know what the reasoning was back then and it may be the same today. From my early conversations with Larry, I recall that the reason is that RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw many abuses of these over the years. Therefore, he decided not to repeat that abomination, limiting it to precisely one level deep. I'm happy for that. Yeah, every once in a while, I've wanted the second layer, but I'm willing to rewrite the statement as a true normal if/while instead of a backwards if/while, and it *does* help the overall readability. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Two Signature questions
:($x where {...} is elk)# ambiguous auxillary
Is this legal? does the 'elk' trait pertain to $x or to the where-block?
:($x is ro is rw) # conflicting traits
Is this legal? Is $x ro or rw?
--
Gaal Yahas [EMAIL PROTECTED]
http://gaal.livejournal.com/
Re: Nested statement modifiers.
Paul Seamons schreef:
In the samples you gave I had to read the entire line to see
what the outcome of the code is.
I was not addressing reading skills, but just your you'd either have
... or One always needs to read the full line, but one doesn't
have to do that linearly or just from left to right.
Read Perl's or as skip if the previous was true, and speed-reading
such
constructs is in your bag.
There are plenty of cases where you too want the conditions up front.
A. $strong_objection1 or $strong_objection2 or
$half_a_reason1 and $half_a_reason2 and $weight *= 1.1 ;
B. $no_way 0.8 or $you_must_be_crazy 0.9 or
$let_s_try 0.6 and $you_never_know 0.5 and $weight *= 1.1 ;
C. $weight *= 1.1 if $let_s_try 0.6 and $you_never_know 0.5
unless $no_way 0.8 or $you_must_be_crazy 0.9 ;
D. unless $no_way 0.8 or $you_must_be_crazy 0.9
{
if $let_s_try 0.6 and $you_never_know 0.5
{
$weight *= 1.1
}
}
E. unless $no_way 0.8 or $you_must_be_crazy 0.9
{
$weight *= 1.1 if $let_s_try 0.6 and $you_never_know 0.5
}
Assuming all variants are alternatives, I prefer E.
A-E aren't alternatives if the value of the (last) evaluated expression
counts:
F. $strong_objection1 or $strong_objection2 !!
$half_a_reason1 and $half_a_reason2 ?? ($weight *= 1.1)
:: weight
:: weight ;
G. $strong_objection1 or $strong_objection2 ?? weight
::
$half_a_reason1 and $half_a_reason2 !! weight
:: ($weight *= 1.1) ;
H. $strong_objection1 or $strong_objection2 ?? weight
::
$half_a_reason1 and $half_a_reason2 ?? ($weight *= 1.1)
:: weight ;
Allowing for multiple nested modifiers allows the action to retain its
significance. After I sent the last email I came across a statement
in the code I was working on that would have phrased better if I
could use both an if and an unless. These things do come up - we
Perl 5 coders have just trained ourselves to do things another ways.
Or use a block. I am all for multiple nested modifiers, but not because
I need the action up front, I just happen to like the lean look.
$weight *= 1.1 if $half_a_reason1 and $half_a_reason2
unless $strong_objection1 or $ $strong_objection2 ;
unless $strong_objection1 or $ $strong_objection2
{
$weight *= 1.1
if $half_a_reason1 and $half_a_reason2 ;
} ;
The biggest setback I see to nested modifiers is that the order of
lexical scopes visually read on the screen are reversed in execution.
But that is already a problem with a single level statement modifier.
I don't think multiple levels introduces any more problem than is
already there.
It's just the same thing. Some people don't have problems using them,
many do.
Plus - if there are multiple modifiers then Perl poetry can get even
better. And everybody wins if Perl poetry is better. :)
say I'm ok
if $i_am_ok
if $you_are_ok
while $the_world_is_ok;
You can't even get near natural language. For example: in natural
language a double negation is often used to emphasize the negation.
--
Affijn, Ruud
Gewoon is een tijger.
Re: request: clarify how symbolic references with OO
Mark Stosberg wrote: ::($meth)(self:); Well, audreyt just made this work (r12960), which I what I what I thought should work in the first place: self.$meth(). So I'm happy. (But my curiosity about the spec for symbolic refs and OO still stands. ) Mark
RE: Big update to the Perl 6 Workplace Wiki
Mark Summersault asked what the license for this Wiki is going to be. Below is what I plugged in for the time being. It's my best guess of what the leading lights of #perl6 and @Larry would be reasonably happy with (and thus it should also be appropriate for something eventually living on or near perl.org). Copyright and License * (c) 2006 under the same (always latest) license(s) used by the Perl 6 /src branch of the Pugs trunk. * See http://svn.perl.org/perl6/pugs/trunk/README for the latest details. * See the GPL-2, Artistic-2.0b5, and MIT files in http://svn.perl.org/perl6/pugs/trunk/LICENSE/ for the full license texts. # FYI. The note below was originally posted on perl.perl6.users. # Thought some folks here should also be interested in this. # # Background: # # http://www.nntp.perl.org/group/perl.perl6.internals/34764 # Announcing the Perl 6 and Parrot wiki workspaces # # http://www.nntp.perl.org/group/perl.perl6.users/357 # From: Andy Lester [mailto:andy[at]petdance.com] # # I'm working with Ask about doing something # at perl.org in the next week or two. Ive just finished a big update to the Perl 6 Workplace Wiki. It got big enough that I started splitting it into subsidiary pages. The main page is still pretty long, but Ive added a table of contents to make it easier to find things on it. Please give it a look, and please add useful stuff to it. http://rakudo.org/perl6/index.cgi # Main page. http://rakudo.org/perl6/index.cgi#the_long_perl_6_super_feature_list http://rakudo.org/perl6/index.cgi?glossary_of_perl_6_terms_and_jargon 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
multi method dispatching of optional arguments
Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Mark Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods
Re: multi method dispatching of optional arguments
Mark Stosberg wrote: Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods I just patched mmd-draft.txt in the pugs tree to try address optionals. Here's what I came up with: == Handling Optional and Slurpy Parameters Optional parameters need special consideration, because they represent two options themselves: one with with the argument and one without. Slurpy parameters have the same concern, as they can take zero or more arguments themselves. For each optional parameter, a case with and without the optional parameter is considered. Examples: Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 Arguments () to signatures 1. (@a?) and 2. () calls 2 Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 Mark
Re: multi method dispatching of optional arguments (further refined)
Mark Stosberg wrote: Hello, I think it would helpful if the spec addressed who wins in MMD when optional arguments are present. I just submitted these failing tests for pugs which illustrate the issue. not ok 11 - Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 not ok 14 - Arguments () to signatures 1. (@a?) and 2. () calls 2 not ok 15 - Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 In summary, matches that should otherwise happen are failing because the optionalness. Reference: http://feather.perl6.nl/syn/S12.html#Multisubs_and_Multimethods I took a break and thought of an important further clarification for this. The updated text is below: == Handling Optional and Slurpy Parameters Optional parameters need special consideration, because they represent two options themselves: one with with the argument and one without. Slurpy parameters have the same concern, as they can take zero or more arguments themselves. For each optional parameter, a case with and without the optional parameter is considered. Examples: Arguments (a = 'b') to signatures 1. () and 2. (*%h) calls 2 Arguments (1 2) to signatures 1. (@a?) and 2. (@a) calls 2 Arguments (1 2 3) to signatures 1. () and 2. (@a?) calls 2 Arguments (@a) to signatures 1. (@a?) and 2. (@a) IS TIE Note that the variant /with/ the parameter can be considered an exact match, but but the variant /without/ it cannot be considered an exact match. That rule makes the following example work: Arguments () to signatures 1. (@a?) and 2. () calls 2
Re: multi method dispatching of optional arguments (further refined)
I don't follow your examples. What is the logic behind them? On 9/3/06, Mark Stosberg [EMAIL PROTECTED] wrote: Examples: Arguments (1 2) to signatures 1. (@a?) and 2. (@a) calls 2 For example, I would expect this one to be ambiguous, because the 1. (@a?) sub introduces two different signatures, 1. () and 1. (@a). When given 1 2, 1. (@a) matches as well as 2. (@a), so it is ambiguous. Arguments (@a) to signatures 1. (@a?) and 2. (@a) IS TIE The only difference I can see between this and the one above is @a vs. 1 2, which ought to behave the same way, right? Note that the variant /with/ the parameter can be considered an exact match, but but the variant /without/ it cannot be considered an exact match. And I expect that if either or both matches the method is considered to be a match. Right? Luke
when calling sets of methods, what happens to the return values?
S12 describes a feature to call sets of methods at the same time: http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods I would like the spec to clarify what happens to the return values of all these methods. I'm fine with a simple answer, such as that they are not available, or only the first or last set of return values is returned. As a use case, we may use of basically this feature in CGI::Application in Perl5, as part the plugin system. Each plugin location is like a method name, and as we get to each point in the code, we look up through the inheritance tree, executing methods at each location. In this case, I think we ignore the return values. Mark
Re: Nested statement modifiers.
From my early conversations with Larry, I recall that the reason is that RSTS/E BASIC-PLUS had nested trailing modifiers, and both Larry and I saw many abuses of these over the years. Therefore, he decided not to repeat that abomination, limiting it to precisely one level deep. I'm happy for that. Thank you. This is the sort of answer I was looking for. Yeah, every once in a while, I've wanted the second layer, but I'm willing to rewrite the statement as a true normal if/while instead of a backwards if/while, and it *does* help the overall readability. I'd concede that the actual useful uses are rare enough to not warrant giving a feature that could turn hopelessly ugly quickly - even if the current generation of tools make it easy to add the feature. Paul
Re: Nested statement modifiers.
Yeah, every once in a while, I've wanted the second layer, but I'm
willing to rewrite the statement as a true normal if/while instead of a
backwards if/while, and it *does* help the overall readability.
I'd concede that the actual useful uses are rare enough to not warrant
giving a feature that could turn hopelessly ugly quickly - even if the
current generation of tools make it easy to add the feature.
Sorry to respond to my own post. As soon as I sent the reply I still felt an
itch for a second level.
I agree that such a thing could be abused as Randal mentioned. But how many
things are there in Perl 5 and Perl 6 that can't be abused (sorry - that is a
sort of subjective thing to ask so I am putting it out hypothetically)? It
still seems odd to take some things out of the language but leave others in
(ok - most things that have been left out have made perfect sense). I'm much
more a fan of the leaving in if the thing being left in doesn't have an
exponential cost and if there isn't a good reason to exclude it.
We still have goto statements. We have map and grep that now go forwards -
but can still go backwards.
Taking it out doesn't necessarily prevent abuses since we now have repeat.
repeat {
repeat {
say Oh no. Not again;
} while $x++ 10;
} while $y++ 2;
As opposed to
say Yes. Yes again
while $x++ 10
while $y++ 2;
Additionally reading the documentation about repeat it seems that the
following should already be allowed since the conditional statement on a
repeat is not optional and if it doesn't come first then it MUST come later
and if it MUST come later then it isn't a modifier.
my $x = 1; repeat { say hello; $x = 0 } while $x if $x;
Though I would expect the following to break because it wouldn't know to parse
for the modifier after the closing brace:
my $x = 1; repeat while $x { say hello; $x = 0 } if $x;
This is what pugs does - though I'm not sure what it means.
pugs my $x = 1; repeat { say hello; $x = 0 } while $x;
hello
0
pugs my $x = 1; repeat { say hello; $x = 0 } while $x if $x;
I think it means that I will probably need to have the correct behavior be
clarified to me, obtain a commit bit and add a test to pugs.
Anyway. Once again if the alleged crime or the predicted crime is too great
then I concede. I can see that it could be abused by some. But that doesn't
mean I will abuse it.
Paul
PS. And not that it matters, but TT3 is planned to support nested statement
modifiers and my engine which does much of TT3 already supports them - and I
do use them on occasion - but that's a different mailing list.
