On Sep 21, 2013, at 1:28 PM, Elizabeth Mattijsen (via RT)
<[email protected]> wrote:
> # New Ticket Created by Elizabeth Mattijsen
> # Please include the string: [perl #119929]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=119929 >
>
> [13:18:06] <lizmat> r: multi sub a ($a) { say "without named" }; multi sub
> a ($a, :$foo) { say "with named" }; a("bar") # bug or feature ??
> [13:18:07] <+camelia> rakudo c5ba78: OUTPUT«with named»
> [13:18:25] <lizmat> given 2 candidates, one without named, and one with an
> optional named
> [13:18:42] <colomon> lizmat: how could that not be a bug?
> [13:18:51] <lizmat> is it right that the candidate with the optional named
> parameter is selected even if there is no named parameter given ?
> [13:19:14] <masak> lizmat: I think in this case, it comes down to
> ordering.
> [13:19:22] <masak> lizmat: I'd need to re-read S06 to be sure.
> [13:19:36] <masak> lizmat: but if it comes down to ordering, I still
> think the first one should win.
> [13:20:15] <lizmat> r: multi sub a ($a, :$foo) { say "with named" }; multi
> sub a ($a) { say "without named" }; a("bar") # which one wins ?
> [13:20:16] <+camelia> rakudo c5ba78: OUTPUT«with named»
> [13:20:32] <lizmat> seems to not be an order thing here
> [13:21:02] <lizmat> seems the candidate without named params is always
> ignored (to me, at least)
> [13:23:12] <lizmat> colomon: how could that not not be a bug ?
> [13:24:13] <FROGGS> n: multi sub a ($a, :$foo) { say "with named $a $foo"
> }; multi sub a ($a) { say "without named $a" }; a("bar") # checking niecza
> [13:24:15] <+camelia> niecza v24-95-ga6d4c5f: OUTPUT«without named bar»
> [13:24:43] <lizmat> rn: multi sub a ($a, :$foo) { say "with named $a $foo"
> }; multi sub a ($a) { say "without named $a" }; a("bar")
> [13:24:48] <+camelia> rakudo c5ba78: OUTPUT«use of uninitialized value of
> type Any in string context in sub a at /tmp/8jPolJRUuH:1with named bar »
> [13:24:48] <+camelia> ..niecza v24-95-ga6d4c5f: OUTPUT«without named bar»
> [13:25:06] <lizmat> I think this calls for either a rakudo or niecza bug
> [13:25:07] <colomon> lizmat: I would (possibly naively) expect the most
> specific multi to win. but the least specific multi is winning. my default
> assumption is bug.
> [13:25:18] <FROGGS> lizmat: I think it should complain about an ambigious
> all
> [13:25:21] <FROGGS> call*
> [13:25:25] <lizmat> that at least
> [13:25:47] <lizmat> but how can "no named parameters" not be narrower than
> "any named parameters" ?
> [13:25:51] <colomon> seems like we've thought up three possible behaviors,
> and rakudo is doing *none* of them.
> [13:26:17] lizmat submits rakudobug
Additionally:
[13:27:02] colomon goes looking in roast
[13:29:15] <colomon> positional-vs-named.t only tests named parameters
declared with exclamation points.
[13:29:26] <colomon> rn: multi sub a ($a, :$foo!) { say "with named $a
$foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13:29:29] <+camelia> rakudo c5ba78, niecza v24-95-ga6d4c5f: OUTPUT«without
named bar»
[13:30:21] <lizmat> colomon: unfortunately, I need *all* named params to be
optional :-(
[13:30:40] <colomon> rn: multi sub a ($a, :$foo?) { say "with named $a
$foo" }; multi sub a ($a) { say "without named $a" }; a("bar")
[13:30:43] <+camelia> niecza v24-95-ga6d4c5f: OUTPUT«without named bar»
[13:30:43] <+camelia> ..rakudo c5ba78: OUTPUT«use of uninitialized value of
type Any in string context in sub a at /tmp/B1iLu772zp:1with named bar »
[13:33:06] <colomon> lizmat: while I agree there's something wonky going on
here, do you really require two different subs? should a("bar") and a("bar",
foo=>False) do different things?
[13:33:25] <lizmat> well, this is about {} and [] accesses
[13:33:46] <lizmat> if there are no named params specified, I would like
it to select the quickest sub
[13:34:08] <lizmat> *now* I have to check all of the passed named
parameters for *each* bare [] and {} access
[13:34:33] <lizmat> aka: $delete & $exists & $kv & $p & $k & $v ===
$default
[13:34:33] <lizmat> ?? SELF.at_key($key)
[13:34:49] <lizmat> rather than just SELF.at_key($key)
[13:35:44] <colomon> I'm not sure forcing rakudo to figure it out with a
multi will be a performance win there.
[13:36:01] <lizmat> it's about being able to do this at compile time
[13:36:08] <colomon> I suppose if you have to have a multi anyway, it's not
a bit deal...
[13:36:11] <lizmat> so each {} and [] access doesn't have to go through a
multi
[13:36:21] <lizmat> but can be optimized to take the right one right away
[13:37:17] <jercos> but that's sort of a perfect-world thing.
[14:02:43] <timotimo> i think foo($a, :$foo) is narrower than foo($a),
because foo($a) is really foo($a, *%)
[14:04:18] <lizmat> timotimo: then there should be an attribute "is
nonamed" or something like that
[14:04:46] <lizmat> because we will need the selection of the simplest
candidate for speed
[14:04:47] <timotimo> hmm
[14:04:51] <timotimo> yes.
