From @lizmat

I’m sending this in as a rakudo bug because I think it is.

We have confusion about what is a Pair and what is a named parameter. I see just about everybody fall into this trap.

The only way I see around this, is to separate the meaning of Pair and named parameter visually as well​:

a => 42 # a Pair
:a(42) # a named parameter

I could also see going as far as making a named parameter an Enum, or a(nother) subclass of it.

Liz

Begin forwarded message​:

Date​: 13 Jun 2015 04​:25​:43 GMT-6
From​: mt1957 <mt1957@​gmail.com>
To​: perl6 users <perl6-users@​perl.org>
Subject​: problem pushing pairs onto an array of pairs

l.s.

Can't push/unshift onto an array of pairs!

Below a repl session with pushes

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Pair @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Array $p = [ a => 1, b => 2];
a => 1 b => 2
$p.push(x=>1);
a => 1 b => 2

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(Pair.new(x=>1));
a => 1 b => 2 (Any) => (Mu)

In all cases the pair x=>1 is not added. The last case is weird to me.

greetings,
Marcel

From 1parrota@gmail.com

Liz is right. If a construct causes a significant number of people to
make a mistake, it's a design flaw that needs to be fixed.

On 6/13/15, Elizabeth Mattijsen <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Elizabeth Mattijsen
# Please include the string​: [perl #​125400]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=125400 >

I’m sending this in as a rakudo bug because I think it is.

We have confusion about what is a Pair and what is a named parameter. I see
just about everybody fall into this trap.

The only way I see around this, is to separate the meaning of Pair and named
parameter visually as well​:

a => 42 # a Pair
:a(42) # a named parameter

I could also see going as far as making a named parameter an Enum, or
a(nother) subclass of it.

Liz

Begin forwarded message​:

Date​: 13 Jun 2015 04​:25​:43 GMT-6
From​: mt1957 <mt1957@​gmail.com>
To​: perl6 users <perl6-users@​perl.org>
Subject​: problem pushing pairs onto an array of pairs

l.s.

Can't push/unshift onto an array of pairs!

Below a repl session with pushes

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Pair @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Array $p = [ a => 1, b => 2];
a => 1 b => 2
$p.push(x=>1);
a => 1 b => 2

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(Pair.new(x=>1));
a => 1 b => 2 (Any) => (Mu)

In all cases the pair x=>1 is not added. The last case is weird to me.

greetings,
Marcel

The RT System itself - Status changed from 'new' to 'open'

From @MARTIMM

On 06/13/2015 04​:06 PM, Elizabeth Mattijsen (via RT) wrote​:

Hi,
May I react on this? Would it be easier to have perl6 throw an error
when there is a named parameter in the call while it isn't defined in
the method. Something like 'Named parameter 'x' not defined by push' in
the example set below. It would start me thinking... It would in any
case be better than saying nothing.

# New Ticket Created by Elizabeth Mattijsen
# Please include the string​: [perl #​125400]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=125400 >

I’m sending this in as a rakudo bug because I think it is.

We have confusion about what is a Pair and what is a named parameter. I see just about everybody fall into this trap.

The only way I see around this, is to separate the meaning of Pair and named parameter visually as well​:

a => 42 # a Pair
:a(42) # a named parameter

I could also see going as far as making a named parameter an Enum, or a(nother) subclass of it.

Liz

Begin forwarded message​:

Date​: 13 Jun 2015 04​:25​:43 GMT-6
From​: mt1957 <mt1957@​gmail.com>
To​: perl6 users <perl6-users@​perl.org>
Subject​: problem pushing pairs onto an array of pairs

l.s.

Can't push/unshift onto an array of pairs!

Below a repl session with pushes

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Pair @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(x=>1);
a => 1 b => 2

my Array $p = [ a => 1, b => 2];
a => 1 b => 2
$p.push(x=>1);
a => 1 b => 2

my @​p = a => 1, b => 2;
a => 1 b => 2
@​p.push(Pair.new(x=>1));
a => 1 b => 2 (Any) => (Mu)

In all cases the pair x=>1 is not added. The last case is weird to me.

greetings,
Marcel

From @jnthn

On Mon Jun 15 06​:12​:13 2015, mt1957@​gmail.com wrote​:

On 06/13/2015 04​:06 PM, Elizabeth Mattijsen (via RT) wrote​:

Hi,
May I react on this? Would it be easier to have perl6 throw an error
when there is a named parameter in the call while it isn't defined in
the method. Something like 'Named parameter 'x' not defined by push'
in
the example set below. It would start me thinking... It would in any
case be better than saying nothing.

Methods ignoring unknown named parameters has been discussed many times over the years. The reason they do so is to properly support deferral to base classes, which may not know how to handle options that subclasses add. We've seen practical use of this, and I believe there's even an outstanding ticket that's a result of NQP's methods failing to do this (when we delegate to an NQP method from a Perl 6 one in Grammar.parse, if I recall correctly).

In general, methods are late bound and flexible, subs are compile-time-bound and more restricted. So methods being more forgiving over unknown named parameters fits the pattern.

More notably, nobody in the years of discussion on the topic has proposed a viable alternative that keeps deferral working. You can't do it with a static analysis because the place you need the ignoring to happen it is in the target of a deferral, and that could be any method. There's no sensible way I can see to track usage of the nameds down the call stack (defining "usage" is hard enough, and even then I suspect the performance implications would not be pretty).

In summary, there's a design trade-off here, and we've come down on the side of "let's make inheritance useful".

Thus, ticket rejected.

/jnthn

@jnthn - Status changed from 'open' to 'rejected'