Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

is assoc('list') gives "MVMArray: Can't pop from an empty array" #6173

Open
p6rt opened this issue Apr 4, 2017 · 4 comments
Open

is assoc('list') gives "MVMArray: Can't pop from an empty array" #6173

p6rt opened this issue Apr 4, 2017 · 4 comments
Labels
LTA Less Than Awesome; typically an error message that could be better

Comments

@p6rt
Copy link

p6rt commented Apr 4, 2017

Migrated from rt.perl.org#131099 (status was 'new')

Searchable as RT131099$

@p6rt
Copy link
Author

p6rt commented Apr 4, 2017

From @zoffixznet

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...

@p6rt
Copy link
Author

p6rt commented Apr 4, 2017

From @zoffixznet

On Tue, 04 Apr 2017 11​:05​:05 -0700, cpan@​zoffix.com wrote​:

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 rakudo/rakudo@f9f0883c6c and Raku/roast@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

@p6rt
Copy link
Author

p6rt commented Jan 12, 2018

From @zoffixznet

On Tue, 04 Apr 2017 15​:42​:50 -0700, cpan@​zoffix.com wrote​:

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.

@p6rt
Copy link
Author

p6rt commented Sep 12, 2018

From @zoffixznet

On Tue, 04 Apr 2017 11​:05​:05 -0700, cpan@​zoffix.com wrote​:

This is partially fixed now for `is equiv` with
rakudo/rakudo@f9f0883c6c and
Raku/roast@75f42755ec

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] Raku/roast@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LTA Less Than Awesome; typically an error message that could be better
Projects
None yet
Development

No branches or pull requests

1 participant