Skip Menu |

Subject: [LTA] is assoc('list') gives "MVMArray: Can't pop from an empty array"
On prefix and postfix ops, using `is assoc('list')` causes an LTA error without any location. I've no idea if it makes sense for them to be assoc list; originally, I came across this while trying to make a postfix op `is equiv(&[orelse])`: $ perl6 -e 'sub prefix:<♥> ($) is prec({:assoc("list")}) { }; ♥42' ===SORRY!=== MVMArray: Can't pop from an empty array $ perl6 -e 'sub postfix:<♥> ($) is prec({:assoc("list")}) { }; 42♥' ===SORRY!=== MVMArray: Can't pop from an empty array $ perl6 -e 'sub postfix:<♥> ($) is equiv(&[orelse]) { }; 42♥' ===SORRY!=== MVMArray: Can't pop from an empty array $ perl6 -v This is Rakudo version 2017.03-20-g027aa54 built on MoarVM version 2017.03-7-g029d121 implementing Perl 6.c. The error points to at gen/moar/stage2/NQPHLL.nqp:1099 (/home/zoffix/.rakudobrew/moar-nom/install/share/nqp/lib/NQPHLL.moarvm:EXPR_reduce) However, I don't know if this should be fixed by throwing when attempting to is assoc list these types of ops or what...
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Tue, 04 Apr 2017 11:05:05 -0700, cpan@zoffix.com wrote: Show quoted text
> On prefix and postfix ops, using `is assoc('list')` causes an LTA > error without any location. > > I've no idea if it makes sense for them to be assoc list; originally, > I came across this while trying to make a postfix op `is > equiv(&[orelse])`: > > $ perl6 -e 'sub prefix:<♥> ($) is prec({:assoc("list")}) { }; ♥42' > ===SORRY!=== > MVMArray: Can't pop from an empty array > > $ perl6 -e 'sub postfix:<♥> ($) is prec({:assoc("list")}) { }; 42♥' > ===SORRY!=== > MVMArray: Can't pop from an empty array > > $ perl6 -e 'sub postfix:<♥> ($) is equiv(&[orelse]) { }; 42♥' > ===SORRY!=== > MVMArray: Can't pop from an empty array > > $ perl6 -v > This is Rakudo version 2017.03-20-g027aa54 built on MoarVM version > 2017.03-7-g029d121 > implementing Perl 6.c. > > The error points to at gen/moar/stage2/NQPHLL.nqp:1099 > (/home/zoffix/.rakudobrew/moar- > nom/install/share/nqp/lib/NQPHLL.moarvm:EXPR_reduce) > > However, I don't know if this should be fixed by throwing when > attempting to is assoc list these types of ops or what...
This is partially fixed now for `is equiv` with https://github.com/rakudo/rakudo/commit/f9f0883c6c and https://github.com/perl6/roast/commit/75f42755ec Per TimToady[^1], we should throw on attempts to use list assoc with non-infix ops. It's a trivial thing to do with normal code, but because a lot of the setting isn't available in traits, it kept giving me compilation issues. There's one way that works, but in that method the check is done AFTER altering the prec (with .prec('assoc') eq... check), which IMO is LTA. I ended up hacking an nqp way with nqp::atkey(%spec) working, but then crashing with `:prec(:assoc<list>)` usage. So, I ended up with this NQP monstrocity: https://gist.github.com/zoffixznet/a68ba013efd5b424ae60734f1da5daaf along with fixing is equiv, is tighter, and is looser to just pass the <prec> key and not all the rest. It gave me a compilation error the 100th time today, so I stashed it and will give it another try another day; unless someone else beats me to it. [1] https://irclog.perlgeek.de/perl6-dev/2017-04-04#i_14375115
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Tue, 04 Apr 2017 15:42:50 -0700, cpan@zoffix.com wrote: Show quoted text
> Per TimToady[^1], we should throw on attempts to use list assoc with > non-infix ops.
From: https://irclog.perlgeek.de/perl6-dev/2018-01-12#i_15683344 14:16 masak re https://rt.perl.org/Public/Bug/Display.html?id=132711 -- associativity *does* make sense for prefix ops. see S03 for the whole scoop 14:17 ...but basically, if you have `!$a!`, where prefix:<!> and postfix:<!> have the same precedence, then those two ops *associate* in the sense of having a left or right associativity 14:17 (I happen to know this because 007 has this behavior, which was copied directly from Perl 6) 14:19 we basically never run into this, because people generally don't tend to make postfixes bind as tightly as prefixes. (they're usually tighter, modulo the fact that Perl 6 has one termish set of precedences and one list-oppy set.) 14:20 but if you ever made a precedence level with both prefixes and postfixes in it, then associativity would totally make sense in the above way. 14:22 masak for all intents and purposes, associativity is something that you set on a whole precedence level, not on individual operators. but since precedence levels are not first-class in Perl 6, we set them on ops. having two ops on the same level differ in associativity is pretty nonsensical, though.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 693b
Show quoted text
> On Tue, 04 Apr 2017 11:05:05 -0700, cpan@zoffix.com wrote:
Show quoted text
FYI: with 6.d prep going on, I reverted[^1] that test for now Don't want to spec the test's behaviour until this ticket and behaviour in related tickets[^2] are entirely resolved/specced [1] https://github.com/perl6/roast/commit/b9c2a956e1dbfe39603 [2] RT#132713, RT#132710, RT#132711, maybe more https://rt.perl.org/Public/Bug/Display.html?id=132713 https://rt.perl.org/Public/Bug/Display.html?id=132710 https://rt.perl.org/Public/Bug/Display.html?id=132711


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