> > 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
> 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
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 th
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 si
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
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
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
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
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
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
:($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/
> "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
ab
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
# 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/grou
14 matches
Mail list logo
