Skip Menu |
Report information
Id: 125487
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: elizabeth <liz [at] dijkmat.nl>
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Date: Fri, 26 Jun 2015 11:25:08 +0200
From: Elizabeth Mattijsen <liz [...] dijkmat.nl>
Subject: Possible MMD issue when binding nqp::null() ??
To: rakudobug [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
[10:57:16] <lizmat> m: use nqp; my %h; %h<a> := nqp::null() #hmmmm [10:57:16] <+camelia> rakudo-moar 3d645f: OUTPUT«Unexpected named parameter 'BIND' passed␤ in block <unit> at /tmp/GYnIiEF0VO:1␤␤» This looks strange to me, as we have the right candidate for this case: multi sub postcircumfix:<{ }>( \SELF, \key ) is rw { # <— we fail here SELF.AT-KEY(key); } multi sub postcircumfix:<{ }>(\SELF, \key, Mu :$BIND! is parcel) is rw { # <— ok candidate?? SELF.BIND-KEY(key, $BIND); } Oddly enough, it looks like BIND-KEY *can* handle the case well: $ 6 'use nqp; my %h; %h.BIND-KEY("a",nqp::null()); say %h.perl' {:a(Mu)}<> A similar issue exists with binding nqp::null() to array elements: $ 6 'use nqp; my @a; @a[0] := nqp::null()' Unexpected named parameter 'BIND' passed in block <unit> at -e:1 $ 6 'use nqp; my @a; @a.BIND-POS(0,nqp::null()); say @a.perl' [Mu]<> I guess the dispatcher cannot see the difference between the absence of a value and nqp::null()? If this is a case of DIHWIDT, then so be it. I was just trying to see if we could make the :delete adverb more sensical for arrays, by making it splice. And introduce a new :null adverbs that would have the current semantics on arrays, and similar semantics on hashes (aka, effectively turning the hash into a SetHash with keys only). Liz
Still reproducible (2017.11,HEAD(e5b660e))

On 2015-06-26 02:25:27, elizabeth wrote:
Show quoted text
> [10:57:16] <lizmat> m: use nqp; my %h; %h<a> := nqp::null()
> #hmmmm
> [10:57:16] <+camelia> rakudo-moar 3d645f: OUTPUT«Unexpected named
> parameter 'BIND' passed␤ in block <unit> at /tmp/GYnIiEF0VO:1␤␤»
>
> This looks strange to me, as we have the right candidate for this
> case:
>
> multi sub postcircumfix:<{ }>( \SELF, \key ) is rw { # <— we fail
> here
> SELF.AT-KEY(key);
> }
> multi sub postcircumfix:<{ }>(\SELF, \key, Mu :$BIND! is parcel) is rw
> { # <— ok candidate??
> SELF.BIND-KEY(key, $BIND);
> }
>
> Oddly enough, it looks like BIND-KEY *can* handle the case well:
>
> $ 6 'use nqp; my %h; %h.BIND-KEY("a",nqp::null()); say %h.perl'
> {:a(Mu)}<>
>
>
> A similar issue exists with binding nqp::null() to array elements:
>
> $ 6 'use nqp; my @a; @a[0] := nqp::null()'
> Unexpected named parameter 'BIND' passed
> in block <unit> at -e:1
> $ 6 'use nqp; my @a; @a.BIND-POS(0,nqp::null()); say @a.perl'
> [Mu]<>
>
>
> I guess the dispatcher cannot see the difference between the absence
> of a value and nqp::null()?
>
> If this is a case of DIHWIDT, then so be it. I was just trying to see
> if we could make the :delete adverb more sensical for arrays, by
> making it splice. And introduce a new :null adverbs that would have
> the current semantics on arrays, and similar semantics on hashes (aka,
> effectively turning the hash into a SetHash with keys only).
>
>
> Liz




This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org