On Sat, Nov 29, 2008 at 1:54 PM, Klaas-Jan Stol via RT
<[EMAIL PROTECTED]> wrote:
> Should we keep the syntax:
>
> .param int "answer" => a
>
> ?
>
> I propose to remove it; it's not been documented, and it doesn't add
> particularly to readability IMHO (the argument-side using arrows, OTOH,
> is u
> >rakudo: sub foo($x?, :$y = 2){ say "$x"~"|"~"$y"}; foo(:y(3));
> >exp_evalbot
> >OUTPUT[|]
>
> This appears to be a bug in Parrot (now RT#54860). When that's fixed
> this one should be fixed also.
RT#54860 is fixed, verified:
rakudo: sub foo($x?, :$y = 2){ say "$x"~"
# in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt3/Ticket/Display.html?id=57410 >
> >
> >
> > hi,
> >
> > afaics, pdd19 does not specify the syntactic sugar for named arguments.
> So,
> > the following i
play.html?id=57410 >
>
>
> hi,
>
> afaics, pdd19 does not specify the syntactic sugar for named arguments. So,
> the following is not specified:
>
> foo( "answer" => 42 )
>
> This syntax is implemented in IMCC.
>
>
> On a side note, the named p
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #57410]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=57410 >
hi,
afaics, pdd19 does not specify the syntactic sugar for named arguments. So,
On Jan 23, 2006, at 17:58, Chip Salzenberg wrote:
On Fri, Jan 13, 2006 at 02:29:49PM +0100, Leopold Toetsch wrote:
At argument opcodes level, a named argument are 2 items: name, var,
where the String 'name' is marked with the :named bit, e.g.:
set_args '(0, 0x80, 0, 0x80, 0)', a, 'c', c, 'b
On Fri, Jan 13, 2006 at 02:29:49PM +0100, Leopold Toetsch wrote:
> At argument opcodes level, a named argument are 2 items: name, var,
> where the String 'name' is marked with the :named bit, e.g.:
>
> set_args '(0, 0x80, 0, 0x80, 0)', a, 'c', c, 'b', b
I was pondering that issue earlier. Inte
As mentioned earlier today, I've rewritten the guts of the argument
passing code. It's now one function 'process_args', which is mostly a
state machine with currently ~12 cases that handles the various states
or should eventually handle.
Anyway, previous functionality
On Jan 13, 2006, at 14:29, Leopold Toetsch wrote:
Below are some thoughts, syntax mainly, how it could look like.
And now a bit of named arguments passing semantics.
0. Call and return are symmetric, I'll use function call here, because
it's more commonly used with named. (Arg
jerry gay wrote:
it's not stated explicitly in your proposal, but what is the proper
location for named params in a sub call? i expect something like
"named arguments must follow all positional (required and optional)
arguments in a sub or method call".
You pass arguments to a
Roger Browne wrote:
On Fri, 2006-01-13 at 14:29 +0100, Leopold Toetsch wrote:
Proposal: Named Arguments...
Your proposal covers all the functionality that I need for Amber,
thanks.
Great.
Leo, would you be so kind as to rescind the parameter passing error
flags, and make mismatches
On 1/13/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Below are some thoughts, syntax mainly, how it could look like.
>
> Proposal: Named Arguments
>
[snip proposal]
>
> Comments welcome,
> leo
>
it's not stated explicitly in your proposal, but what is the pr
On Fri, 2006-01-13 at 14:29 +0100, Leopold Toetsch wrote:
> Proposal: Named Arguments...
Your proposal covers all the functionality that I need for Amber,
thanks.
> b = new .Integer
> c = 3
I'm sure everyone realised, but just for the sake of completeness: the
first id
Below are some thoughts, syntax mainly, how it could look like.
leo
Proposal: Named Arguments
pdd03 is already mentioning named arguments, but a concrete syntax
is still missing, as well as how it could work.
First a snippet of the proposed syntax:
.sub named_test :main
.local pmc a, b, c
14 matches
Mail list logo
