[perl #131243] [REGEX] Interpolating a Hash in a regex treats it as a list and errors out

[Sam S. via RT]

On Tue, 02 May 2017 08:35:34 -0700, c...@zoffix.com wrote:
> Both of these forms produce the error below
> 
> my %stuff = ;
> say 'foo bar meows' ~~ m:g/ %stuff\S+ /;
> say 'foo bar meows' ~~ m:g/ %() \S+ /;
> 
> # P6opaque: no such attribute '$!reified' in type List when trying to
> get
> # a value in block  at z2.p6 line 8
> 
> What did I expect to happen? No idea, I just randomly tried the code.
> If it's not meant to work then at least a better error should be
> shown.

S05 says¹:

The use of a hash variable in patterns is reserved.

So yes, this should be made to throw a nicer error.

---
[1] http://design.perl6.org/S05.html#Variable_(non-)interpolation

[perl #132352] Set operators unfriendly to mutable types

[Sam S. via RT]

On Mon, 23 Oct 2017 05:23:55 -0700, c...@zoffix.com wrote:
> Set operators are a lot less useful with mutable types, like SetHash,
> because
> even when one of the operands is a SetHash, they still return a Set,
> making
> constructs like `∖=` or `∪=` entirely unusable:
> 
> my $days = SetHash.new: Date.today … Date.new: '2014-04-02';
> $days ∖= $days.grep: *.key.day-of-week > 5;
> dd $days.^name; # "Set"
> $days{Date.today}:delete; # Cannot call 'DELETE-KEY' on an immutable
> 'Set'

I don't think setty operators always returning Set, is that different from 
listy operators/methods (Z, grep, map...) always returning Seq.

For example, when you write:

   @foo .= grep: * %% 2;

Then the grep returns a Seq, and and its the assignment to the Array variable 
which makes sure that in the end you'll have the results as an Array. (Still 
the same Array, in fact, just with new contents.)

If you were to use a Scalar variable, you would get essentially the same issue 
as in your quoted Set example:

   $foo .= grep: * %% 2;  # Oops, $foo is now an immutable Seq.

The "solution", IMO, would not be to make your quoted example work (by adding 
further special cases to the return types of the setty operators or otherwise), 
but rather to make the following variation of it work:

my %days is SetHash = Date.today … Date.new: '2014-04-02';

%days ∖= %days.grep: *.key.day-of-week > 5;

%days{Date.today}:delete;

...and then promote %-sigiled SetHash variables as the recommended way to store 
SetHash'es.

It should be possible to make this last example work by implementing `method 
STORE` for type SetHash, right?

(That it currently doesn't, may well be an oversight rather than a design 
choice.)

[perl #124527] [BOGUSTEST] [REGEX] S05-metasyntax/interpolating-closure.t line:28 reason: 'dunno'

[Sam S. via RT]

This look like a bogus test to me.

On the RHS of the ~~ operator, `$_` is bound to the LHS string "aaabccc".

`$var ??` evaluates the regex $var in boolean context, which causes it to match 
against this string.

Since there is no match, this causes the ternary operator to return the 
`rx{abc}` branch, which in turn matches at the current position in the outer 
regex.

So unless I'm missing something, it is wrong for the test to expect no match 
for the outer regex, and Rakudo already does the right thing.

What's the protocol for removing/changing tests in roast?

[perl #132217] [UNI] `unival` ignores everything but first chars

[Sam S. via RT]

On Tue, 03 Oct 2017 17:52:39 -0700, c...@zoffix.com wrote:
> Perhaps it should throw when it was given trailing stuff after the
> relevant char?
> 
> 00:49   dpk m: say unival("1\x[300]23")
> 00:49   camelia rakudo-moar 98fae3: OUTPUT: «1␤»
> 00:50   dpk that … seems like a potential security issue for some
> apps
> 00:51   m: say unival("1\x[300]dasdsadsadsadsadasdsa")
> 00:51   camelia rakudo-moar 98fae3: OUTPUT: «1␤»

I assume it's modeled after `ord`, which also does this:

➜  say "Hello".ord;  # 72

...which in turn probably does it because its Perl 5 version always did it:

$  perl -E 'say ord "Hello"
72

Whether this is really the best thing to do, or if a warning/error would be 
better, I don't know.

Note that Perl 6 also has plural versions of all three of these though, which 
give the result for every character in the string:

➜  .say for "123".ords;
49
50
51

➜  .say for "123".uninames;
DIGIT ONE
DIGIT TWO
DIGIT THREE

➜  .say for "123".univals;
1
2
3

[perl #127906] [REGEX] Sequential array interpolation `||@foo` doesn't backtrack

[Sam S. via RT]

It affects `|` array interpolation as well:

➜  say "ab" ~~ / < ab a > b /;# ｢ab｣
➜  say "ab" ~~ / @() b /;   # Nil
➜  say "ab" ~~ / |@() b /;  # Nil

[perl #127906] [REGEX] Array interpolation depends on order of array elements

[Sam S. via RT]

On Wed, 20 Jul 2016 08:32:12 -0700, c...@zoffix.com wrote:
> I was able to golf it a bit further (still present in Rakudo 58dc8c).
> Removing >> or changing first-match || to longest-match | no longer
> shows the bug:
> 
> m: "bc" ~~ /||@() >>/ or say "Failed"
> rakudo-moar 58dc8c: OUTPUT«Failed␤»

Still present in:

This is Rakudo version 2017.09-227-g8ff76b596
built on MoarVM version 2017.09.1-575-gd4e230a6
implementing Perl 6.c.

And it's not specific to `>>`. Even simpler test-case:

➜  say "abc" ~~ /[ a || ab ] c/;  # ｢abc｣
➜  say "abc" ~~ /||@() c/;  # Nil

It looks like it simply refuses to backtrack into `||@`.

[perl #130906] [TESTNEEDED] [REGRESSION] Reducing a Seq with `=>` fails with "P6opaque: no such attribute '$!reified' in type List"

[Sam S. via RT]

Tests committed: https://github.com/perl6/roast/commit/9ea27ad2e

Closing.

[perl #130117] [TESTNEEDED] [REGEX] Sequential alternation `||` does not respect `:ratchet`

[Sam S. via RT]

Tests were added here: https://github.com/perl6/roast/commit/65a762217

[perl #131973] [TESTNEEDED] [REGEX] Backtracking modifiers on individual atoms fail to override a regex-global `:ratchet` modifier.

[Sam S. via RT]

Tests were added here: https://github.com/perl6/roast/commit/65a762217

[perl #126951] [TESTNEEDED] Interpolating a typed hash into an argument list produces wrong keys

[Sam S. via RT]

Test added: https://github.com/perl6/roast/commit/8773139c37

Closing.

[perl #131936] [TESTNEEDED] [REGRESSION] [REGEX] Match.made leaks a `NQPMu`

[Sam S. via RT]

Test were added by Zoffix a month ago:
https://github.com/perl6/roast/commit/8674f1e8c

Closing.

[perl #126757] [LTA] error message talks about ~ but there is no ~ in my code (33..126 .pick.chr)

[Sam S. via RT]

On Wed, 04 Oct 2017 22:10:22 -0700, alex.jakime...@gmail.com wrote:
> To produce an error message that is more precise we'll need more
> information
> than just a line number, but we don't have that during the run time.

Couldn't the confusing wording be fixed without additional information?

As I understand it, the problem with the current message is that the

in '⏏~' (indicated by ⏏)

part leads people to think it's referring to a position in the source code, 
when it is actually referring to a position in a string. Especially because the 
"in block ... in file ... at line ..." line comes directly after it.

[perl #131003] [ANNOYING][SEGV] Heap corruption when using Gumbo

[Sam S. via RT]

What is the point of the `[ANNOYING]` tag?
All bugs are probably annoying to *someone*...

[perl #131973] [RFC] Backtracking modifiers on individual atoms fail to override a regex-global `:ratchet` modifier.

[Sam S. via RT]

On Mon, 28 Aug 2017 09:20:33 -0700, sml...@gmail.com wrote:
> I sent a pull request to nqp that fixes this, please review:
> 
> https://github.com/perl6/nqp/pull/368

The PR was merged (and Rakudo's nqp version bumped).

Marking the ticket TESTNEEDED. (Note that some possible tests are listed in the 
PR description!)

[perl #130117] [REGEX] Sequential alternation `||` does not respect `:ratchet`

[Sam S. via RT]

On Mon, 28 Aug 2017 11:50:51 -0700, sml...@gmail.com wrote:
> I sent a pull request which fixes this bug:
> 
> https://github.com/perl6/nqp/pull/368
> 
> Please review.

The PR was merged (and Rakudo's nqp version bumped).

Marking the ticket TESTNEEDED. (Note that some possible tests are listed in the 
PR description!)

[perl #132185] [LTA] file tests and Failure do not interact as expected

[Sam S. via RT]

On Sat, 30 Sep 2017 13:47:22 -0700, allber...@gmail.com wrote:
> So I included at least one discussion in the ticket that was utterly
> pointless and left unread. At this point I'm just going to assume only
> half-exposing the underlying mechanism is considered a feature and I need
> to use a different language when it's not.

You mean the part about exposing different stat() error conditions?

A `Failure` wraps a typed exception, which you can get at by calling the 
`.exception` method on it:

my $is-file = do given $path.f -> $result {
with $result.?exception {
when X::IO::DoesNotExist { ... }
when ... { ... }
when ... { ... }
default  { ... }
}
$result.so
}

(...or by letting it throw and then using a CATCH block.)

Exceptions also have type-specific attributes which can hold further details to 
differentiate similar but different error conditions.

If file tests should be made to expose more fine-grained error states (probably 
a good idea), they can use those two mechanisms without the need to change 
anything about Failure or add new syntax.

PS: At the end of the day, "only half-exposing the underlying mechanism" of 
low-level operating-system APIs is to be expected though, for a high-level 
language that wants to be cross-platform and user-friendly. Getting full access 
to specific operating-system APIs is what third-party modules such as [1] are 
for. Thankfully, Perl 6's NativeCall interface makes them relatively easy to 
write.


---
[1] https://github.com/cspencer/perl6-posix

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Sam S. via RT]

On Sat, 30 Sep 2017 13:13:31 -0700, c...@zoffix.com wrote:
> Don't see a reason why not.

Well, passing a 'type' string parameter to select between what is essentially 
different object sub-types, seems internal-ish.

I can't think of anything else in the public Perl 6 API which does this; a more 
Perl 6'ish API would dispatch based on *different* named parameters, or simply 
make the object sub-types available as separate subclasses.

So it might make sense to consider `Junction.new` as "not public API" for now, 
until this is ironed out.

> If it weren't, all fixed bugs still need a test to cover them.

Noted; Marking the ticket as TESTNEEDED.

A test for the current behavior could look like:

use Test;
throws-like { Junction.new }, X::Multi::NoMatch, "Junction.new with no 
arguments";

[perl #132185] [LTA] file tests and Failure do not interact as expected

[Sam S. via RT]

I agree with Zoffix that this seems to be fine as is.

Generally speaking, IO operations that logically require an existing path will 
return a Failure if the path does not in fact exist:

  Slurp its content? Failure.
  Rename/move/copy it? Failure.
  Check its size? Failure.
  Check if it is of type "directory? Failure.
  Check if it is of type "file"? Failure.

Whereas `.e`, i.e. checking if a path exists, is by necessity *not* an 
operation that assumes an existing path.

The only thing that might be debatable, is whether `.f` should mean:

   a) Check if it is of type "file".

   b) Check if it exists, and if so, if is of type "file".

The current behavior (a) seems more natural and useful to me though.

Perl 5 does (a) as well, in the sense that it too distinguishes "failure" from 
"no" in the return value:

 - "yes, it is of type 'file'":  a defined truthy value
 - "no, it is not of type 'file'":  a defined falsy value
 - "failure, it does not exist so its type can not be checked":  `undef`

Perl 6 merely improves on that by promoting the failure condition from `undef` 
to `Failure`, which both carries more information and provides more safety by 
default.

To the extent that you're basing your expectations on the fact that a Perl 5 
`undef` can be used in ways that a Perl 6 `Failure` cannot (without blowing 
up), well, that's just a matter of having to unlearn Perl 5 (or other 
programming languages) while learning Perl 6... :)

[perl #131395] Using a cross meta operator on an empty list complains about not supporting elems

[Sam S. via RT]

On Mon, 29 May 2017 11:36:49 -0700, c...@zoffix.com wrote:
> On Mon, 29 May 2017 10:02:27 -0700, thunderg...@comcast.net wrote:
> > Using a cross meta operator on an empty list complains "This type 
> > (Scalar) does not support elems".
> > 
> >  say (1,2).elems; say ().elems; say (1,2) X ();
> > 
> > yields "2␤0␤This type (Scalar) does not support elems"
> > 
> > Seems to work correctly with arrays instead of lists.
> > 
> >  say [1,2].elems; say [].elems; say [1,2] X [];
> > 
> > 
> > Linux Mint 17.2
> > 
> >  >perl6 -v
> >  >This is Rakudo version 2017.05 built on MoarVM version 2017.05 
> > implementing Perl 6.c.
> 
> 
> Thank you for the report. lizmat++ fixed the issue.
> 
> Fix: https://github.com/rakudo/rakudo/commit/9494cbd3b9
> Test: https://github.com/perl6/roast/commit/0faf3c354f

Re-opening, because it hasn't been fixed for the Xop case yet:

➜  say () X+ (1, 2);
This type (Scalar) does not support elems

➜  say (1,2) X~ ();
This type (Scalar) does not support elems

➜  say () X=> ();
This type (Scalar) does not support elems

Bisectable¹ blames a commit² from January.


---
[1] https://gist.github.com/Whateverable/f1b3066f1e2c45df7ab5e0aa7aeee3a7
[2] https://github.com/rakudo/rakudo/commit/a26f51361

---
This is Rakudo version 2017.09-142-ga89add0bf built on MoarVM version 
2017.09.1-49-gb3dd812a
implementing Perl 6.c.

[perl #131490] Crash in Junction:D.BUILDALL `This type (Scalar) does not support elems`

[Sam S. via RT]

On Fri, 02 Jun 2017 18:58:22 -0700, c...@zoffix.com wrote:
> While chasing some other bugs, came across this one:
> 
>  m: Junction.new.BUILDALL: {}
>  rakudo-moar ef9872: OUTPUT: «This type (Scalar) does not
> support elems␤  in block  at  line 1␤␤»
> 
> Not sure how much it matters in itself, but figured I'd report it, in
> case it's a symptom of a bigger bug.

This can be golfed to just:

Junction.new;

And it has been fixed to throw a better error message now:

➜  Junction.new;
Cannot resolve caller new(Junction: ); none of these signatures match:
(Junction $: \values, Str :$type!, *%_)
(Junction $: Str:D \type, \values, *%_)

According to bisectable¹, it was fixed by a commit² in June.

The 'bigger issue' was possibly RT #131395.

Is `Junction.new` meant to be public API?
If not, do we still need a test for this?

---
[1] https://gist.github.com/Whateverable/13556140482322fd5bf4080092a1d284
[2] https://github.com/rakudo/rakudo/commit/61ecfd511

[perl #126092] pairs X pairs can't bind to subsig

[Sam S. via RT]

On Fri, 18 Sep 2015 00:51:42 -0700, larry wrote:
> 00:13 < TimToady> m: for (1,2,3).pairs X (4,5,6).pairs -> ($x,$y) { say "$x
> $y" }
> 00:13 <+camelia> rakudo-moar c0e0c9: OUTPUT«This type cannot unbox to a
> native string␤  in block  at /tmp/YnA_LhZbRO:1␤␤»

It gives a nicer error message now:

➜  for (1,2,3).pairs X (4,5,6).pairs -> ($x,$y) { say "$x $y" };
Too few positionals passed to ''; expected 2 arguments but got 0 in 
sub-signature
  in block  at -e line 1

The reason for the error is that sub-signatures use `.Capture`, and 
`List.Capture` turns Pair elements into named arguments:

➜  dd (a => 1, 42, b => 2).Capture;
\(42, :a(1), :b(2))

I too have got bitten by this trap before - it essentially makes it unsafe to 
pass lists containing Pair objects to code (think e.g. a third-party module) 
that expects arbitrary lists of objects, unless you can ensure that the code 
doesn't and never will end up binding the list to a sub-signature (or otherwise 
calling `.Capture` on it).

It's IMO also conceptually dubious. A List firmly represents the concept of 
"list of positional elements", and I see no compelling conceptual reason why 
`.Capture` should second-guess this meaning based on the *type* of the list 
elements.

So I can only assume that it works like it does now, for practical reasons - 
i.e. because something in core relies, or used to rely, on it working this way. 
But what?

Note that flattening things into argument lists *doesn't* suffer from this 
issue, because instead of `.Capture` it uses `.FLATTENABLE_LIST` + 
`.FLATTENABLE_HASH` which always cleanly treat list elements as positionals and 
hash entries as nameds.

Marking this ticket as [@LARRY].

[perl #132121] [REGEX] (RFC?) Overflow of writing to captures

[Sam S. via RT]

On Mon, 18 Sep 2017 10:45:21 -0700, c...@zoffix.com wrote:
> Apparently it's possible to assign to capture variables to change what
> the resultant Match will have.
> 
> The first question: is this actually something specced and supported?
> Especially the fact that further captures continue their numbering
> from the capture we wrote into

This is documented in the design docs as intentional:

http://design.perl6.org/S05.html#Numbered_scalar_aliasing

(Except for the overflow bug, of course.)

[perl #132120] [REGEX] Accessing captures from another capture fails a match

[Sam S. via RT]

On Mon, 18 Sep 2017 09:00:54 -0700, c...@zoffix.com wrote:
> IRC: https://irclog.perlgeek.de/perl6/2017-09-18#i_15181575
> 
> We can use $0 here to refer to previous capture and regex matches:
> m: say "11" ~~ /(\d)[$0]/
> rakudo-moar 48a84d: OUTPUT: «｢11｣␤ 0 => ｢1｣␤»
> 
> But if we capture that match, the match fails:
> m: say "11" ~~ /(\d)([$0])/
> rakudo-moar 48a84d: OUTPUT: «Nil␤»

Not a bug.

Each `( )` capture represents a subpattern¹ that builds its own Match object, 
and inside the subpattern, `$/` refers to this subpattern's Match (which in 
your case doesn't have any captures) and not to the parent pattern's Match 
(which has the capture you meant to access).
(PS: Remember that `$0` is just an alias for `$/[0]`.)

I don't think there's a built-in way to access a parent pattern's Match object 
- you'll have to manually pass on the object in a variable or similar, like you 
already discovered in the linked IRC log.

This ticket can IMO be closed as 'rejected', but I'll leave it open for now in 
case I missed something obvious or in case you want to turn it into an RFC or 
similar.


---
[1] http://design.perl6.org/S05.html#Subpattern_captures

[perl #122504] [TESTNEEDED] 'return' invoked outside of a routine should throw an exception

[Sam S. via RT]

> It looks to me like the tests already in S04-statements/return.t
> should suffice, no?

You're right. Closing the ticket.

[perl #126139] [BUG] [GLR] nested lazy cross operators confuse the continuations

[Sam S. via RT]

Merged two commits that I'm pretty sure are about the same issue.

On Tue, 22 Sep 2015 18:09:54 -0700, larry wrote:
> 18:00 < TimToady> m: my @v := [1, 2]; my \step1 = 8 X* ^4; my \step2 = @v
> X+> step1; say step2 X% 256;
> 18:00 <+camelia> rakudo-moar 631ac4: OUTPUT«===SORRY!===␤Cannot invoke this
> object (REPR: Uninstantiable)␤»

The original test-case posted by larry is among the ones that works correctly 
now, since¹ the aforementioned performance-optimization commit.

Golfed example that used to blow up before that commit, but now works:

say (1, 2 X* (3 X+> 4));

Golfed example that still blows up:

say (1, 2 Xand (3 Xand 4));

---
[1] https://gist.github.com/Whateverable/a662877edcb635eff937adb1f5c34275

[perl #130612] [REGEX] [@LARRY] LTM doesn't use text order for tie break as expected

[Sam S. via RT]

Confirmed on IRC that this is a bug.

Relevant log¹ (edited for clarity):

Is it intended that LTM prefers \d and <[0..9]>
  over  and <:Number>, as a tie-breaker?
  (re. RT #130612)

no, that wasn't intended

   m: say '1' ~~ / \d |  { say 'digit' }/
 rakudo-moar 760530: OUTPUT: «｢1｣␤»
   m: say '1' ~~ /  { say 'digit' } | \d /
   Interesting
  Though I can guess why

   m: say '1' ~~ / \d | <:N> { say 'digit' }/
 rakudo-moar 760530: OUTPUT: «｢1｣␤»
   m: say '1' ~~ /<:N> { say 'digit' } | \d/
 rakudo-moar 760530: OUTPUT: «｢1｣␤»

   That one I don't understand

---
[1] https://irclog.perlgeek.de/perl6/2017-09-11#i_15149008

[perl #126332] [BUG] .assuming ignores anything from the second argument onwards in Rakudo

[Sam S. via RT]

On Mon, 12 Oct 2015 05:33:13 -0700, masak wrote:
>  m: my  := ('hello world'); say f(0, 2);
>  rakudo-moar 70a94d: OUTPUT«hello world␤»
>  m: say ('hello world')(0, 2)
>  rakudo-moar 70a94d: OUTPUT«hello world␤»
> [...]

It works fine now:

➜  say ("hello world")(0, 2);
he

➜  say { @_ }.assuming(1, 2)(3, 4, 5);
[1 2 3 4 5]


According to committable¹ and bisectable², this was a regression introduced 
near the start of the GLR around Sept 2015, and fixed again by a GLR-related 
commit³ in Dec 2015.

Can be closed with tests.
---
[1] https://gist.github.com/Whateverable/47d41dd4ca8092815ba0449f8a8ee518
[2] https://gist.github.com/Whateverable/8212d24ae0b3498ca53cdd46471db402
[3] https://github.com/rakudo/rakudo/commit/88a8a00

[perl #130612] [BUG] LTM doesn't use text order for tie break as expected

[Sam S. via RT]

Actually...

Rakudo *does* generally follow interpretation (b):

➜  'x' ~~ / .* { say '*' } | .? { say '?' } /;  # *
➜  'x' ~~ / .? { say '?' } | .* { say '*' } /;  # ?

The observed bug is specifically with character classes:

➜  '1' ~~ /  { say 'digit' } | <[0..9]> { say '0..9' }  /;  # 0..9
➜  '1' ~~ /<[0..9]> { say '0..9' }  |   { say 'digit' } /;  # 0..9

Following some more experimentation, here are various atoms for matching the 
digit '1', sorted into three categories based on how much LTM favors them in 
current Rakudo:

tier 1:  '1'
tier 2:  .   \d   \w   <[0..9]>
tier 3:<:Number>   <:Decimal>   etc.

That the literal `1` is preferred over everything else by LTM is to be expected 
("longest literal prefix" tie-breaker).

However, that the character classes are split into two tiers - with the 
syntactic ones being preferred over the named and uniprop ones - seems strange.
At least I don't see anything in S05 to back that up.

http://design.perl6.org/S05.html#Overview says that LTM is transitive through 
subrules, so even if the named character classes are treated as subrule calls 
they shouldn't be disfavored, right?

[perl #130612] [BUG] LTM doesn't use text order for tie break as expected

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.

---

However, there's also a design question to be answered here:

On Sat, 21 Jan 2017 10:32:39 -0800, ronaldxs wrote:
> https://design.perl6.org/S05.html#Longest-token_matching says:
> # For matches of same length ... If the alternatives are in the same
> # grammar file, the textually earlier alternative takes precedence.

This S05 paragraph was clearly written with LTM of `proto` regexes in mind.

What does it mean for LTM of `|` alternations?

I.e., should the test-case above match 'n'...

a) because `token n { ... }` is declared above `token na_2 { ... }`?
b) because in ` | `, ` ` is to the left of ` `?

The test-case at hand does not distinguish between those two interpretations 
(Rakudo is currently wrong either way), but it's an important distinction that 
needs to be clarified if the bug is to be fixed.

http://design.perl6.org/S05.html#Overview has a sentence on this tie-breaker 
which actually mentions alternations:

> Within a given compilation unit, the earlier alternative or multi wins

I'd interpret that as option (b), but am not 100% sure.

[perl #132066] [BUG] Code blocks cause backtracking fail in `|` alternation with ratcheting

[Sam S. via RT]

PS: This *really* needs to be properly documented on http://docs.perl6.org 
though - I've submitted a ticket for that here:

https://github.com/perl6/doc/issues/1550

[perl #132066] [BUG] Code blocks cause backtracking fail in `|` alternation with ratcheting

[Sam S. via RT]

On Mon, 11 Sep 2017 09:48:01 -0700, dzw...@gmail.com wrote:
> `|` matches the longest input:
> > 'ab' ~~ / ^:ratchet [ . | .. ] $ /
> ｢ab｣
> 
> If the regex contains empty code blocks, backtracking fails:
> > 'ab' ~~ / ^:ratchet [ {}. | {}.. ] $ /
> Nil

Not a bug.

As the S05 design document explains¹, the longest-token matching performed by a 
`|` alternation only considers the declarative prefix of each branch when 
comparing their match length.

The declarative prefix is everything from the start of the branch until just 
before the first atom that is considered "procedural" rather than "declarative" 
- such as a `{ }` closure.

In your example, the declarative prefix of both branches is always zero-length, 
because they have a `{ }` closure right at the start - so the `|` considers 
both branches equally long and thus always chooses the first one (unless 
backtracking forces it to reconsider).

Closing this ticket.

---
[1] http://design.perl6.org/S05.html#Longest-token_matching

[perl #126117] [BUG] defined value as type constraint is accepted and doesn't work

[Sam S. via RT]

On Sun, 20 Sep 2015 09:17:21 -0700, zef...@fysh.org wrote:
> Presumably using a defined value (anything other than a type object)
> as a type constraint should be a semantic error.

It does throw a compile-time error for the `my` declaration now, however the 
error message is not appropriate:

➜  constant T = 3; my T $a; say $a; $a = 3; say $a;
===SORRY!=== Error while compiling:
Variable definition of type Int (implicit : by pragma)
requires an initializer
--> constant T = 3; my T $a⏏; say $a; $a = 3; say $a;
expecting any of:
constraint

According to bisectable¹, this new behavior was introduced by a commit² by 
FROGGS in Oct 2015.

That commit implemented Type:D and Type:U types, and the "implicit : by pragma" 
part of the error message is actually meant to print something like "implicit 
:D by pragma", except apparently it also catches the unrelated issue of this RT.

It should be made to print a more appropriate message in this case.

Marking this as an LTA ticket.

---
[1] https://gist.github.com/Whateverable/a6f61fac5114f64747a8a9d913e2f3d7
[2] https://github.com/rakudo/rakudo/commit/80a3d07

[perl #126125] [LTA] malformed "my" spuriously claims lack of type declaration

[Sam S. via RT]

On Sun, 20 Sep 2015 14:00:53 -0700, zef...@fysh.org wrote:
> Presumably the "malformed my" error is correct, but the preceding "type
> 'Any' is not declared" is bogus.

It now no longer prints the bogus "type 'Any' is not declared" error, only the 
correct "malformed my" error:

➜  my Any⏏ :D $a;
===SORRY!=== Error while compiling:
Malformed my
--> my Any⏏⏏ :D $a;

Bisectable6 reports¹ that it was fixed by a commit² in November 2015.

It should be possible to test in roast that this throws `X::Syntax::Malformed` 
and not whatever "type not declared" uses, right?

Marking the ticket TESTNEEDED.

---
[1] https://gist.github.com/Whateverable/ee54f5241e3cb77ea3969ff3481d8d9b
[2] https://github.com/rakudo/rakudo/commit/e1e03e6

[perl #126269] [BUG] unexpected behavior for reduced composition

[Sam S. via RT]

On Mon, 05 Oct 2015 09:10:42 -0700, grond...@yahoo.fr wrote:
> The following two expressions should give the same result:
> 
> $ perl6 -e 'say ([o] (1 + 1/*), (2 + 1/*))(Inf);'
> 1.5
> 
> $ perl6 -e 'say ([o] (++$ + 1/*) xx 2)(Inf);'
> 3

What's happening is that the `++$` operation isn't evaluated only once (when 
the WhateverCode is constructed), but actually becomes part of the WhateverCode 
and is evaluated each time the WhateverCode is called:

my  = ++$ + *;
say a 0;  # 1
say a 0;  # 2
say a 0;  # 3

That's nothing specific to `++` or `$`, e.g. consider:

my  = rand + *;
say a 0;  # 0.949744965798848
say a 0;  # 0.842127241122708
say a 0;  # 0.716049843395635

As jnthn explained on IRC:

‎<‎jnthn‎>‎ Yeah, if the + is being whatever-curried then the
LHS is going to be pulled into the thunk as a whole
‎<‎jnthn‎>‎ It's a compile-time transform

To create a different WhateverCode on each iteration as you intended, make it 
close over the loop variable:

say ([o] do for 1..2 { $_ + 1/* })(Inf);  # 1.5

TL;DR: Working as intended.

Closing this ticket.

[perl #122345] [BUG] Returning from a parameter list default counts as returning 'outside of any Routine' in Rakudo on Moar

[Sam S. via RT]

On Sun, 20 Jul 2014 10:29:57 -0700, masak wrote:
> < masak> r: sub { sub foo($x = return) { $x }; say foo }(); say "alive"
>  rakudo-jvm bbdcfd: OUTPUT«alive␤»
>  ..rakudo-moar bbdcfd: OUTPUT«Attempt to return outside of
> any Routine [...]
>  ..rakudo-parrot bbdcfd: OUTPUT«alive␤Nominal type check
> failed for parameter '$x'; expected Any but got Mu instead␤»

This works now with Rakudo MoarVM as well.

➜  sub { sub foo($x = return) { $x }; say foo }(); say "alive";
alive

bisectable6 reports¹ that it was fixed by one of these commits:

https://github.com/rakudo/rakudo/commit/e609822
https://github.com/rakudo/rakudo/commit/615d30c
https://github.com/rakudo/rakudo/commit/8beb87b
https://github.com/rakudo/rakudo/commit/05170e0
https://github.com/rakudo/rakudo/commit/899e0fd
https://github.com/rakudo/rakudo/commit/e544376
https://github.com/rakudo/rakudo/commit/fcd0093
https://github.com/rakudo/rakudo/commit/04929fe
https://github.com/rakudo/rakudo/commit/7ee6578
https://github.com/rakudo/rakudo/commit/519e764

Ticket can be closed with tests.

---
[1] https://gist.github.com/Whateverable/7807d6ff7d2e1d059172c7cb784bd4d7

[perl #122504] [BUG] 'return' invoked outside of a routine should throw an exception

[Sam S. via RT]

A `return` outside a routine now always seems to throw a run-time error, as it 
should:

$  perl6 -e 'return'   
Attempt to return outside of any Routine
  in block  at -e line 1

$  perl6 -e '{ return }' 
Attempt to return outside of any Routine
  in block  at -e line 1

$  MVM_SPESH_DISABLE=1 perl6 -e '{ return }'
Attempt to return outside of any Routine
  in block  at -e line 1

Bisectable points to this fix from Dec 2015:

https://gist.github.com/Whateverable/63b5da597e229d167d8708a43d4501de
https://github.com/rakudo/rakudo/commit/a4ca12a

This ticket can be closed once tests are added to roast.

[perl #121327] [BUG] Array shift in loop in loop in loop shifts from an outdated array (on second iteration) in Rakudo

[Sam S. via RT]

It works fine now:

➜  for ^2 { my @b = 1 xx 4; say (@b.shift xx 2) xx 2 }
((1 1) (1 1))
((1 1) (1 1))

Was apparently fixed a year ago:

https://gist.github.com/Whateverable/e2a6fe61150eb2595ac0ff6929daeab1
https://github.com/rakudo/rakudo/commit/5e61516

Can be closed with tests.

[perl #111474] [BUG] Variable in string in <{ }> interpolator in regex doesn't get a proper lookup in Rakudo

[Sam S. via RT]

On Thu, 01 Mar 2012 13:07:28 -0800, masak wrote:
>  nom: '' ~~ / :my $a; <{ '$a' }> /
>  nom 48af8c: OUTPUT«===SORRY!===␤Variable $a is not
> declared␤at eval_0:1␤»

This works fine now - and has so for a while¹, apparently since a commit² in 
May 2015:

say '123' ~~ / :my $a=2; <{ '$a' }> /, # '2'

---
[1] https://gist.github.com/Whateverable/1df76358c7486886538f9ead60b13d1f
[2] 
https://github.com/rakudo/rakudo/commit/f0e142b3a24e60f4bdde145286d508b916f3ecde

[perl #121991] [BUG] Unless 'use soft' is in play, .wrap should die in Rakudo

[Sam S. via RT]

On Fri, 30 May 2014 09:51:18 -0700, masak wrote:
>  m: sub a {"foo"}; sub b {"bar"~callsame}; (); say a();
>  rakudo-moar 90cd58: OUTPUT«foo␤»

This now works:

➜  sub a {"foo"}; sub b {"bar"~callsame}; (); say a();
barfoo

Is TimToady's recommendation of forbidding `.wrap` on routines that aren't 
under `use soft`, still relevant?


---
This is Rakudo version 2017.08-104-g76f1d8970 built on MoarVM version 
2017.08.1-148-g1059eed1
implementing Perl 6.c.

[perl #120995] [BUG] Error when passing the same named argument twice using different aliases

[Sam S. via RT]

On Mon, 13 Jan 2014 18:28:14 -0800, m...@kli.org wrote:
> > sub f(:a(:b($x))) { say $x }
> sub f(Any :a(:b($x))) { ... }
> > f(:a("A"), :a("B"))
> B
> > f(:a("A"), :b("B"))
> Unexpected named parameter 'a' passed

I've had a look at `src/Perl6/Metamodel/BOOTSTRAP.nqp`, which is where the 
error message is thrown, and this is what seems to be happening:

---

1) A Hash called `$named_args` is created¹ from the incoming Capture, holding 
the named arguments that were passed.
If two different aliases were used on the calling side, then this Hash will 
obviously contain two separate entries.

2) The code then iterates over all parameters declared in the signature², and 
when it encounters a named parameter, it makes the list of the parameter's 
aliases available as a variable called `$named_names`³.

2b) It then iterates over this list of aliases, and for each one checks if 
`$named_args` contains an entry with that name. If so, it deletes⁴ that key 
from `$named_args` and stops looking⁵.

3) A it completed iterating over the whole signature, it checks⁶ whether 
there's anything left over in `$named_args`, and throws the exception quotes 
above if there is.

---

I am unsure how to properly fix this.

Removing the line `$j := $num_names;`⁵ which stops the code from looking 
further once it finds *one* alias of the named arameter for which the incoming 
Capture has a value, should make the error go away (untested)...

...but then multiple such arguments would override each other based on the 
order the aliases are declared in the signature, rather than the order in which 
the arguments are passed on the calling side... which would surely break user 
expectations.

The problem is that, AFAIK, the Capture doesn't even *remember* which order 
differently named arguments were passed in, because internally it stores them 
in a Hash.

So unless I'm missing something, this "bug" either requires invasive changes to 
Rakudo, or we need to accept it as something that can't be fixed and content 
ourselves with trying to improve the error message.

Tagging the issue with [@LARRY] to invite a decision from a core dev.

--
[1] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L649
[2] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L661
[3] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L749
[4] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L838
[5] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L839
[6] 
https://github.com/rakudo/rakudo/blob/dfbd39b/src/Perl6/Metamodel/BOOTSTRAP.nqp#L878

[perl #120995] Same argument present multiple times is okay with one name, not with two

[Sam S. via RT]

On Mon, 13 Jan 2014 18:28:14 -0800, m...@kli.org wrote:
> > sub f(:a(:b($x))) { say $x }
> sub f(Any :a(:b($x))) { ... }
> > f(:a("A"), :a("B"))
> B
> > f(:a("A"), :b("B"))
> Unexpected named parameter 'a' passed
> 
> If nothing else, the error message is LTA. But basically we're allowed
> to pass
> the same named parameter in twice if we use the same name, but not if
> we use
> different names.

This bug is still present in

This is Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.

[perl #114684] [BUG] Return type mismatch should return Failure, not throw exception

[Sam S. via RT]

On Fri, 31 Aug 2012 12:36:48 -0700, pmichaud wrote:
> 19:34  r:  sub abc() returns Int { my $r = 3.5; $r  };  my
> $x = abc();  say 'alive';
> 19:34  rakudo 231137: OUTPUT«Type check failed for return
> value; expected 'Int' but got 'Rat'␤  in sub abc at /tmp/P8uacuh4gB:1␤
> in block  at /tmp/P8uacuh4gB:1␤␤»

Still the same in current Rakudo:

This is Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.

Better test-case:

➜  sub abc() returns Int { 3.5 }; say abc.defined;
Type check failed for return value; expected Int but got Rat (3.5)

Since there has been no update on this, and no-one's complaining about the 
current behavior, does this mean the ticket should be rejected?

(Marking it RFC for now.)

[perl #113628] [BUG] error when doing a hyper-mutate-flip on an array

[Sam S. via RT]

On Wed, 13 Jun 2012 23:13:01 -0700, masak wrote:
>  r: (my @) ».=« flip
>  rakudo 90333b: OUTPUT«===SORRY!===␤ResizablePMCArray: Can't
> shift from an empty array!␤»

Still present in:

This is Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.

It addition to an error, it now also prints a bogus "useless use" warning.

➜  my @a = ;  @a »~=» '1';  dd @a;
Array @a = ["ab1", "xy1"]

➜  my @a = ;  @a ».=» flip;  dd @a;
Potential difficulties:
Useless use of ».=« in sink context
at -e:1
--> my @a = ;  @a ⏏».=» flip;  dd @a
===SORRY!===
Method call node requires at least one child

Here shown with the the right-facing hyper meta-op `» »`, which makes more 
sense here (though all forms currently fail in the same way).

Expected result for each form, IMO:

».=»

Array @a = ["ba", "yx"]

«.=»

Array @a = ["ba", "yx"]

».=«

ERROR:
Lists on either side of non-dwimmy hyperop of .= are not of
the same length
left: 2 elements, right: 1 elements

«.=«

ERROR:
Lists on either side of non-dwimmy hyperop of .= are not of
the expected length
left: 2 elements, right: 1 elements

[perl #111912] [BUG] Composing an inherited class through a parametric role doesn't work in Rakudo

[Sam S. via RT]

On Wed, 21 Mar 2012 08:32:55 -0700, masak wrote:
>  nom: role A[::T $] { also is T }; class B { }; class C does
> A[B] { }; say C ~~ B
>  rakudo 1a468d: OUTPUT«===SORRY!===␤Cannot type check against
> type variable T␤»

Now it throws earlier, and with a nicer error message:

===SORRY!=== Error while compiling -e
T does not support inheritance, so A cannot inherit from it

Not sure if it can be made to work like you wanted.

Not sure if it can be made to actually work (i.e. defer the `also is T` until 
class composition time, at which point the concrete type of T would be 
available).

Seems related to: https://rt.perl.org/Ticket/Display.html?id=130634

[perl #107844] [BUG] .wrap and 'is export' don't play along in Rakudo

[Sam S. via RT]

On Tue, 10 Jan 2012 02:16:07 -0800, masak wrote:
>  about wrap again: https://gist.github.com/1585730
> 
> Included here for completeness:
> 
> ┌─[tadzik@yavin4]─[~/src/perl/bailador] (master)*
> └─[%]─> cat lib/Bailador.pm
> module Bailador;
> 
> our sub our_template {
> return "(our template)"
> }
> 
> sub exp_template is export {
> return "(exp template)"
> }
> 
> sub hook is export {
> _template.wrap: { "wrapped {callsame()}" };
> _template.wrap: { "wrapped {callsame()}" };
> }
> ┌─[tadzik@yavin4]─[~/src/perl/bailador] (master)*
> └─[%]─> cat examples/app.pl
> use Bailador;
> 
> sub foo {
> say Bailador::our_template();
> say exp_template();
> }
> 
> hook();
> 
> foo();
> ┌─[tadzik@yavin4]─[~/src/perl/bailador] (master)*
> └─[%]─> perl6 examples/app.pl
> wrapped (our template)
> (exp template)

This bug is still present in current Rakudo:

This is Rakudo version 2017.08-104-g76f1d8970
built on MoarVM version 2017.08.1-148-g1059eed1
implementing Perl 6.c.

(Test script now needs s/module/unit module/ to run, but then produces the same 
result.)

Calling `_template.WHICH` also confirms that the one in the module and the 
one in the mainline scope are different objects.

[perl #95970] [BUG] Code.callwith introduces an official CALLER frame in Rakudo

[Sam S. via RT]

On Sat, 30 Jul 2011 14:19:40 -0700, masak wrote:
>  is there a method for invoking a Routine? besides
> postcircumfix:<( )>, I mean?
>  rakudo: sub foo($a) { say $a }; (42)
>  rakudo 922500: OUTPUT«42␤»
>  That's what I thought when I saw .callwith :)
>  oh, interesting, .callwith without being in a call already :)
>  why do you need anything besides .() ?
>  moritz: I don't, I'm just thinking ahead :)
>  Code.callwith(...) has no relation to callwith(...)
>  oh!
>  that's... unfortunate...
>  I dunno if the first is even tested, fwiw.
>  I guess if we have it it's spec
>  But it seems kinda...well...pointless.
>  hm, yes. S06:1146 mentions something of the sort.
>  "Use of C allows the routine to be called without
> introducing an official C frame."
>  that seems to be why.
>  should've been named .gotowith :P
>  oh
>  well, we don't do that. :)
> * masak submits rakudobug
> * jnthn doesn't bother re-adding it to nom :)
>  masak: use callframe() to prove it :-)
>  rakudo: sub foo { my $foo; () }; sub bar { my
> $bar; say callframe.my }; foo
>  rakudo 922500: OUTPUT«$bar  [...]
>  that's good enough.
> * masak adds that to the ticket

It now fails with:

No such method 'callwith' for invocant of type 'Sub'

Looks like the method forms of `callwith` & friends that S06 proposed, didn't 
make it into Perl 6.c

Marking the ticket NYI.

[perl #132042] [CONC] rakudo hangs while concurrently walking trees

[Sam S. via RT]

Even simpler test-case:

for ^1 { start say $_ }

For me, this almost always hangs (after printing a few dozen or few hundred 
lines), with the MoarVM version currently used by Rakudo nom:

MoarVM version 2017.08.1-128-gde6dced

But *no longer* hangs with MoarVM master (which has the fix by ugexe++):

MoarVM version 2017.08.1-148-g1059eed1

\o/

Marking this ticket as TESTNEEDED.

[perl #132047] [BUG] Splicing Seq into array installs immutable values

[Sam S. via RT]

On Fri, 08 Sep 2017 18:37:50 -0700, tomentiru...@gmail.com wrote:
> 
> > my @h
> []
> > @h.splice: 0, 0, 1.Seq
> []
> > @h[0].VAR.WHAT
> (Int)
> > @h[0] = 5
> Cannot modify an immutable Int (1)
>   in block  at  line 1
> 
> I got hit by this with: @a.splice: 0, 0, Any xx 2

Good find.

It's also not specific to `Seq` - it looks like it happens whenever the 
replacement elements are passed to `splice` as a nested structure rather than 
as flat arguments:

my @h;
@h.splice: 0, 0, 'a';
@h.splice: 1, 0, ('b',);

dd @h;# Array @h = ["a", "b"]
say @h[0].VAR.^name;  # Scalar
say @h[1].VAR.^name;  # Str

Conceptually¹⁺², the `splice` routine takes the replacements as a `*@` slurpy, 
so whether they're passed in nested or flat form should not matter.

But Rakudo currently implements the routine with a `| is raw` signature:

say Array.^find_method("splice").signature;  # (Mu $: | is raw)

...and apparently does the parameter flattening manually, in a way that 
introduces this bug.

Until it is fixed, a work-around is to flatten the replacement elements into 
the argument list of `splice` using `|`:

@a.splice: 0, 0, |(Any xx 2);

---
[1] https://docs.perl6.org/routine/splice
[2] https://design.perl6.org/S32/Containers.html#splice

[perl #132052] [BUG] size passed as parameter to parametric Buf.new method die with error

[Sam S. via RT]

It doesn't seem to be specific to type `size_t` - it also happens with other 
native types such as `int`.

Shorter example:

➜  sub a (int $a) { Blob[int].new($a) };  say a 12;
Type check failed in initializing element #0 to Blob[int]; expected int but 
got Int (12)

Examples that *don't* fail:

➜  sub a (int $a is copy) { Blob[int].new($a) };  say a 12;
Blob[int]:0x<0c>

➜  sub a (Int $a) { Blob[int].new($a) };  say a 12;
Blob[int]:0x<0c>

➜  my int $a = 12;  say Blob[int].new($a);
Blob[int]:0x<0c>

I think it's safe to say that in all four cases, `$a` gets boxed to an `Int`.

But in the first case, it's as if the Blob constructor nonetheless uses the 
code path for `int` and subsequently gets surprised.

Maybe the `int $a` signature leads the compiler to think that it will always be 
an `int`?

[perl #132051] [BUG] Parametric type object passed as literal die with error

[Sam S. via RT]

Although that particular error message seems to be specific to `Blob`, it also 
breaks with other parametric roles (such as `Array`), because the generic 
parameter T of the outer role seems to be passed through without being 
specialized first.

Shorter examples:

➜  role R[::T] { method a { Array[T].new } };  say R[Int].a.perl;
No such method 'perl' for invocant of type 'T'
  in block  at  line 1

➜  role R[::T] { method a { Blob[T].new } };  say R[Int].a.perl;
concatenate requires a concrete string, but got null
  in any protect at gen/moar/stage2/NQPCORE.setting line 1033
  in method a at  line 1
  in block  at  line 1

Looks related to https://rt.perl.org/Ticket/Display.html?id=131947 .

[perl #129878] [BUG][UNI] Stringifying a List adds in spaces between each item

[Sam S. via RT]

On Wed, 06 Sep 2017 15:20:17 -0700, coke wrote:
> With a recent rakudo, these now both output 1

Bisectable shows that it was fixed during recent MoarVM changes:

https://gist.github.com/Whateverable/01a82d07e8009c7beffe5893432dddf2
https://github.com/rakudo/rakudo/commit/593fa5f

Among the listed MoarVM commits, this one seems to be the most likely candidate 
based on its commit message:

https://github.com/MoarVM/MoarVM/commit/62f66cbf

Marking this ticket TESTNEEDED.

[perl #132014] [REGEX] Some Zero-Width assertion appear to not work in

[Sam S. via RT]

Duplicate of https://rt.perl.org/Ticket/Display.html?id=131964 ?

[perl #126249] $/ constructed just once in [REGEX]

[Sam S. via RT]

This has been fixed by TimToday in April, in one of these commits:

https://gist.github.com/Whateverable/23122ebe34ebeccfdfc3cd04845c54f4
https://gist.github.com/smls/aff6a56c1cfcce5c7779251aee394e42

Tests needed.

[perl #132004] [REGEX] Recursion causes infinite loop, even if it can't match anything and another LTM branch can.

[Sam S. via RT]

Shorter example:

grammar Flail {
token TOP {  'w' | 'v' }
}

Flail.subparse('vww').say;

[perl #132003] grammar cannot parse from Blob/Buf

[Sam S. via RT]

In Perl 6.c, regexes/grammars can only parse strings (at the grapheme level).

If you want to parse a Blob or Buf, you have to decode it into a string first 
by calling the `.decode` method¹ on it.

Early Perl 6 design documents² suggested support for parsing at the byte or 
code-point level, but this hasn't become part of the language yet.
I suspect it might be added in a future version.

Marking this ticket [NYI].

---
1) https://docs.perl6.org/routine/decode
2) http://design.perl6.org/S05.html#line_476

[perl #131983] [BUG] mixin thread safety

[Sam S. via RT]

@David

I think this is not a thread safety issue, but rather a result of `role`s 
(intentionally) not being closures.

I.e. a duplicate of this RT: This is a duplicate of 
https://rt.perl.org/Ticket/Display.html?id=130965

[perl #131985] [BUG] curly-brace interpolation thread safety

[Sam S. via RT]

Possibly related to:

https://rt.perl.org/Ticket/Display.html?id=131871

[perl #130947] [BUG] Multi-dimensional Hash subscripts return a List even when indexing a single element

[Sam S. via RT]

I sent a pull request which fixes this bug:

https://github.com/rakudo/rakudo/pull/1139

[perl #130117] [REGEX] Sequential alternation `||` does not respect `:ratchet`

[Sam S. via RT]

I sent a pull request which fixes this bug:

https://github.com/perl6/nqp/pull/368

Please review.

[perl #131973] [RFC] Backtracking modifiers on individual atoms fail to override a regex-global `:ratchet` modifier.

[Sam S. via RT]

I sent a pull request to nqp that fixes this, please review:

https://github.com/perl6/nqp/pull/368

On Mon, 28 Aug 2017 05:53:36 -0700, coke wrote:
> At this stage, something's presence in one of the SYN doesn't mandate
> that it needs to be present in rakudo.

I'd say this particular issue is pretty clearly a fix for an unintended 
oversight/bug in Rakudo's implementation of the interaction between two 
existing features:

1) `:r` which controls backtracking for the rest of the lexical scope it's in.
2) `:` / `:!` which controls backtracking for a single atom.

The reasonable way for these to interact, is for the the more general one 
(which also by necessity comes first in the source code) to be overridden by 
the more specific one (which also comes later in the source code).

The opposite (current Rakudo behavior in the demonstrated edge case) makes no 
sense, because if combining the general and specific modifier has the same 
effect as just the general one on its own, then there is not point in combining 
them in the first place. (And indeed this is also why I don't expect any 
negative fallout from this change.)

A third option would theoretically be possible: *Forbid* combining the two 
features altogether, i.e. throw an exception. But there would have to be a 
pretty un-obvious reason to choose this over option A, and if there was one, 
the S05 authors would have probably thought of it.
More importantly, Rakudo *already* does the common-sensical option A for other 
backtrackable atoms (i.e. quantifiers) - it's just for *alternation* atoms that 
atom-specific backtracking control is silently ignored when a lexical 
`:ratchet` is active.

My patch to fix this¹ also tracked the current behavior to a probable thinko in 
a nested logic expression.

TL;DR: This shouldn't be fixed *because* S05 says so, S05 is merely supporting 
evidence for there not being some obscure reason to not consider this a bug 
when it looks, quacks, etc. like a bug.
But point taken, I'll learn to de-emphasize² the synopsis viewpoint in future 
bug reports... :)

---

1) 
https://github.com/perl6/nqp/pull/368/commits/ba165c8d9a1a5bb17841a0fcf2334b8993251155
2) I'd also like to point out, though, that not all synopses are created equal 
- S05 is one of the ones to which Perl 6 has ended up adhering most faithfully 
(not counting some NYI features). Not consulting it at all, when deciding what 
is or isn't an unintended bug in Perl 6 regex land, would be a mistake...

[perl #131936] [REGRESSION] [REGEX] Match.made leaks a `NQPMu`

[Sam S. via RT]

Fixed by lizmat in commit:


https://github.com/rakudo/rakudo/commit/5db5b1dbfa0b625130573574e2409972387e9f75

Tests needed.

[perl #130117] [REGEX] :r does not prevent backtracking (say ‘abcz’ ~~ /:r [‘a’ || ‘abc’ ] ‘z’ /)

[Sam S. via RT]

Relevant:

https://rt.perl.org/Ticket/Display.html?id=123934#txn-1401917

In short, `||` alternations don't respect `:` in Rakudo, whereas `|` 
alternations (and other atoms such as quantifiers) do respect it.

Simpler test-case:

➜  say "ab" ~~ / [ "ab" | "a" ]: "b" /;
Nil

➜  say "ab" ~~ / [ "ab" || "a" ]: "b" /;
｢ab｣

(Remember that `:ratchet` simply adds `:` to every atom.)

[perl #129845] [CONC] `.dir` returns corrupted `IO::Path`s under concurrent load

[Sam S. via RT]

Both the demo script (from the top post) and the one-line test case (2nd post) 
now pass without error!

Bisectable identifies a commit from last week as the fix:

https://gist.github.com/97d96022fdfed416e67ecadf5b2b9353
https://github.com/rakudo/rakudo/commit/231cb3f

Is there a way to write a spectest for a probabilistic bug like this?

[perl #130773] [BUG] Bogus "Useless use" warning for WhateverCode in EVAL

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #130711] [REGEX] `**` quantifier with dynamic count, misbehaves under `:exhaustive` matching

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #130602] [BUG] `1, 2 Xand "ab".ords` fails with "Cannot invoke this object (REPR: Uninstantiable; Callable)"

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #130572] Parenthesized `for` loop is eager, even with `lazy` keyword

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #130604] [PARSER] Weirdness when mixing `..` and `...` without parens

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #126951] [BUG] Interpolating a typed hash into an argument list produces wrong keys

[Sam S. via RT]

Shorter test-case:

➜  say :{ a => 1, b => 2 }.FLATTENABLE_HASH;
{Str|a => a => 1, Str|b => b => 2}

Compare to a normal Hash which works fine:

➜  say { a => 1, b => 2 }.FLATTENABLE_HASH;
{a => 1, b => 2}

[perl #126951] [BUG] Interpolating a typed hash into an argument list produces wrong keys

[Sam S. via RT]

This bug is still present in

Rakudo version 2017.08-8-g753c9a5ea built on MoarVM version 
2017.08.1-19-g151a2563
implementing Perl 6.c.

[perl #131956] Zen/Whatever slice ignore :v

[Sam S. via RT]

I'm surprised that zen slices accept adverbs at all.

Isn't the whole point of a zen slice to return the invocant object directly, 
without looking at its elements or constructing a slice from them?

I would probably make it print an error along the lines of:

===SORRY!===
Adverbs don't make sense on a zen slice.
To get a slice of all elements, use the Whatever-star: %foo[*]:v
--> say %foo[]⏏:v

(As the title of the ticket says, Whatever-slices *also* ignore :v, so that 
should be fixed of course.)

[perl #113042] [BUG] [WEIRD] LTA internals-leaky error message when doing 'for our $:: ();' in Rakudo

[Sam S. via RT]

Is this still considered a BUG/LTA?

Isn't the error messages it prints now (see last comment by coke) pretty 
reasonable?

[perl #130910] [WEIRD] Sometimes parameterized regexes print nonsense about the number of arguments (/<smth(42)>/)

[Sam S. via RT]

Sorry, copy-pasto in the second-to-last output listing. It is:

meh start
meh end
$ = ｢a｣
Too few positionals passed; expected 2 arguments but got 1
  in regex meh at [...]

[perl #130910] [WEIRD] Sometimes parameterized regexes print nonsense about the number of arguments (/<smth(42)>/)

[Sam S. via RT]

It has to do with backtracking, because:

1) The problem disappears when `:ratchet` mode is enabled in the top-level 
regex:

➜  my regex meh ($t) { . };
➜  say "ab" ~~ /^ :ratchet  $ /;
Nil

2) The problem disappears when the named regex is made a `token`:

➜  my token meh ($t) { . };
➜  say "ab" ~~ /^  $ /;
Nil

Of course, the regex engine could avoid backtracking entirely in that example, 
but maybe it's just not optimized enough to know that.
Here's a different example in which backtracking is actually necessary:

my regex meh ($t) {
{ say "meh start"}
.+?
{ say "meh end"}
}

say "abcde" ~~ /
^
  { say '$ = ', $ }
$
/;

It outputs:

meh start
meh end
$ = ｢abcde｣
Too few positionals passed; expected 2 arguments but got 1
  in regex meh at [...]

Note how the error message appears after having reached the end of the regex 
for the first time, just before it would have backtracked into `meh` for the 
first time.

In comparison, when removing the parameterization of `meh`, the example prints 
the following (Note how it backtracked into `meh` four times, like it should):

meh start
meh end
$ = ｢a｣
meh end
$ = ｢ab｣
meh end
$ = ｢abc｣
meh end
$ = ｢abcd｣
meh end
$ = ｢abcde｣

In summary, what *appears* to be happening, is this:

- If a named subrule is called with parameters...
- And it matched...
- But then the regex engine wants to backtrack into it...
- Then it "calls" the subrule again, but fails to pass the parameters again.

[perl #131932] Inconsistency: `:<^^>` evaluates Callables, but regular `^^` doesn't

[Sam S. via RT]

It's the same with && and ||:

➜  :<&&>(1, -> {say 2});  # 2
➜  say 1 && -> {say 2}; # ->  { #`(Block|169403552312) ... }

➜  :<||>(0, -> {say 2});  # 2
➜  say 0 || -> {say 2}; # ->  { #`(Block|786414142008) ... }

And also with the loose-precedence versions `and`, `or`, `xor`.

And also with `xx`:

➜  :(-> {say 2}, 2)
2
2

➜  say -> {say 2} xx 2
(->  { #`(Block|315591575136) ... } ->  { #`(Block|315591575208) ... })

I.e., it's apparently a general rule for "thunky" operators.

Whether it's intentional, I don't know.

The design docs don't mention it: 
https://design.perl6.org/S03#Tight_and_precedence

[perl #131925] [BUG] [REGEX] Smartmatch against `m//` operator mishandles junctions

[Sam S. via RT]

bisectable6: say .any ~~ m/a/;
 smls, On both starting points (old=2015.12 new=e3e29c5)
  the exit code is 0 and the output is identical as well
 smls, Output on both points: «False»

[perl #131925] Smartmatching a junction against a regex object vs m// (‘a’|‘b’ ~~ m/‘a’/)

[Sam S. via RT]

The problem only appears if `m//` is used directly as the RHS of `~~`:

$_ = 'a' | 'b';
say m/a/;   # any(｢a｣, Nil)
say $_ ~~ m/a/; # False
say $_ ~~ { m/a/ }; # any(｢a｣, Nil)

[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe

[Sam S. via RT]

Heh, on further thought, they may be the same issue after all.

In  `/(...) { ... $i ... $0 ... }`,  both the $i and the $0 (or $/ rather) are 
outer lexicals from the point of view of the curly block, right?

So it might be a general problem with the way that *code blocks inside regexes* 
access outer lexicals.

(It doesn't happen with code blocks *outside* of regexes, and as the other 
ticket demonstrates, also doesn't happen inside the regex-portion of regexes.)

[perl #131870] [CONC] [REGEX] Capture lookup inside regex is not threadsafe

[Sam S. via RT]

Also notable is that multiple iterations somehow see the same value for `$i` 
(as observed in the output listing above).

I've sumbitted a separate issue for that (RT #131871), because the 
Capture-lookup bug of the current issue occurs even when removing the `$i`.

[perl #131783] [LTA] :delete holes in Arrays get turned to Mus when coercing to List or Slip

[Sam S. via RT]

> Which then goes back to: what is the use case of Slipping an Array?

Same as slipping any other type of Iterable: Fine-grained, elegant flattening 
and concatenating.

Compare:

  my @all = flat $first, @rest;

  my @all = $first, |@rest;

When you *know* that $first is a Scalar and @rest is an Array, those two do the 
same thing because `flat` doesn't descend into item containers.

But if those are, say, function parameters, then they can become bound to other 
things, e.g. the calling code could pass a List to `@rest` which *doesn't* have 
its elements itemized, so the version with `flat` would destroy the elements' 
internal structure.

Even if that wasn't the case, I'd consider the `|` version more elegant than 
the `flat` version, because it denotes very clearly to the reader *where* 
exactly something is being flattened into the outer list.

> because Slip is a List, it uses List.AT-POS, and that one
> doesn’t create a WHENCE with a container to be filled at a later time. 

Couldn't `@array.Slip` be made to properly iterate @array behind the scenes 
(the same way that `@array.map` would iterate it), instead of reaching into 
@array's guts and copying its elements in a way that misinterprets some of them?

[perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list

[Sam S. via RT]

On Tue, 18 Jul 2017 07:45:16 -0700, joshu...@gmail.com wrote:
> My thinking is that doing `[X] ((3,2),)` is kinda like doing `[X] 
> ((3,2),Empty)`...

Assuming I understand your analogy correctly, that's exactly what's *not* 
happening, and is why this RT exists. See:

dd [X] 3, 2;   # ((3, 2),).Seq
dd [X] (3, 2); # ((3, 2),).Seq
dd [X] ((3, 2),);  # ((3, 2),).Seq

The first two are unsurprising, but note how the third one is *also* being 
treated as the Cartesian product between the two sets `3` and `2`, rather than 
the single set `(3, 2)`.

Also, scenarios where the argument list to `[X]` or `[Z]` is fixed-sized (like 
in these examples), isn't what is tripping people up (because there's no reason 
to write that in the single-sublist case anyway). The problem is with crossing 
or zipping a variable-sized list of lists, like in `my @transpose = [Z] 
@matrix;`, which works fine for most inputs but breaks down for the "@matrix 
has exactly one row" edge-case. I've explained why this is happening and why it 
ruins people's day in this docs ticket: [1], and this StackOverflow answer: [2].

---
[1] https://github.com/perl6/doc/issues/1400
[2] 
https://stackoverflow.com/questions/44821983/recursive-generator-manual-zip-vs-operator/44831926#44831926

[perl #126895] Cannot constrain an optional parameter with a subset type

[Sam S. via RT]

This bug is still present in

This is Rakudo version 2017.06-251-g23ad2c388 built on MoarVM version 
2017.06-91-g146c8fcc
implementing Perl 6.c.

[perl #131754] [LTA] Error message when using a term bareword as if it were a subroutine

[Sam S. via RT]

A possibly better way to phrase it:

===SORRY!=== Error while compiling [...]
Constant "foo" is followed by another term at [...]
--> say foo⏏ 4;
If your meant to refer to the subroutine "foo" declared at [...],
then either:
* Use `foo(...)` to disambiguate.
* Rename the constant declared at [...] to not clobber the
  subroutine's name.

[perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list

[Sam S. via RT]

I agree that things like

   my @divisors = [X] @prime-factor-powers;
   
   my @transpose = [Z] @matrix;

look perfectly reasonable and elegant, and the fact that the single-sub-list 
edge-case ruins them is regrettable. Nor can I image any scenario where the 
current behavior of that edge-case is useful.

I assumed that because it was the natural result of a core Perl 6 design 
decision which is surely not under discussion anymore (the "single-argument 
rule" for list-munging routines like `zip` and `cross`), we would have to live 
with it.

But  Aleks-Daniel is right, it really would be great to find some way to "fix" 
this edge-case. Here's a first idea:

---

Maybe `reduce` could simply introspect the operator and if sees that the 
signature starts with a "single-argument slurpy" parameter (`+foo` / `+@foo`), 
adapt the calls to it accordingly?

At first glance that seems LTA (special cases are icky), but consider that:

1) `reduce` *already* introspects its operator and adapts its operation 
accordingly, in order to provide maximum DWIM regarding associativity, unity, 
etc.

2) The "single-argument rule" can be seen as just another calling convention. 
When we write `zip @foo`, the the parser may think a function is being called 
with one argument... but *we* know that we're sending all the sub-lists of @foo 
to be zipped, and that if we had wanted to send the single list @foo we would 
have had to write `zip (@foo,)` or `zip $@foo`.
`reduce` also knows that it wants to apply the operator to a single item in the 
edge-case in question, and it could adapts its call to make that happen for 
whatever calling convention the operator uses.

Point (2) raises the question if other built-ins like `map` and `grep` would 
have to learn about different calling conventions as well, for consistency.
But I don't think that's necessarily the case. Things like `map` are very 
generic in the sense that they don't understand anything about what is being 
piped through them... the user is fully in charge of controlling the inputs and 
outputs of the callback. (Also, the current behavior is actually useful there.)
`reduce` is more high-level, in the sense that it knows it's dealing with an 
operator and a list of elements to fold, and wants to call the operator with 
either zero, one or two of those elements at a time.

This shouldn't be interpreted as an RFC yet, just some thoughts. Someone would 
have to thoroughly think through the implications, and test the 
spectest/ecosystem fallout.

[perl #128758] Reduce with numeric ops does not numify things if only one arg is passed ([*] set(1,2,3))

[Sam S. via RT]

It looks like this bug hasn't been *completely* fixed:

dd :<+>( "2" );   # 2
dd :<*>( "2" );   # 2

dd [*] "2"; # 2
dd [+] "2"; # 2

dd reduce :<*>, "2";  # 2
dd reduce :<+>, "2";  # "2"

i.e. it doesn't work when using the + operator with the functional form of 
reduce, even though it works with other numeric operators and with the 
meta-operator form.

[perl #131397] semicolon subscripting in multi dim arrays has odd interactions with numeric string indexes

[Sam S. via RT]

Shorter example:

my @a = [2, 4], [6, 8];
say @a[1; 1].perl;  # 8
say @a["1"; "1"].perl;  # (8,)

PS: Definitely seems related to the following ticket:
https://rt.perl.org/Ticket/Display.html?id=130947

[perl #127974] [CONC] sprintf() not threadsafe/reentrant if the format tokens use explicit indices

[Sam S. via RT]

Still present in

Rakudo version 2017.05-272-gfa7aa1c36 built on MoarVM version 
2017.05-25-g62bc54e9
implementing Perl 6.c.

[perl #128462] [BUG] Unspace after a sigil-less term causes parser error

[Sam S. via RT]

This bug is still present in

This is Rakudo version 2017.05-272-gfa7aa1c36 built on MoarVM version 
2017.05-25-g62bc54e9
implementing Perl 6.c.

[perl #128054] [BUG] In a string enclosed in parens, a {}-interpolation can't access the topic $_ of a statement modifier

[Sam S. via RT]

This bug is still present in

This is Rakudo version 2017.05-134-g0c5fe56cc built on MoarVM version 
2017.05-25-g62bc54e9
implementing Perl 6.c.

[perl #126569] [BUG] xx-repeated expression enclosed in parens can't access the topic $_ of a statement modifier

[Sam S. via RT]

Still present in

This is Rakudo version 2017.05-134-g0c5fe56cc built on MoarVM version 
2017.05-25-g62bc54e9
implementing Perl 6.c.

[perl #126595] Cannot bind a Seq to a variable list

[Sam S. via RT]

This was fixed by Zoffix one month ago (including tests):

https://rt.perl.org/Ticket/Display.html?id=131222#txn-1458062

Closing.

[perl #128866] [BUG] Array[Int] ~~ Array[Numeric] is false

[Sam S. via RT]

> How come last one should be same? Aren't they different types? I'd expect 
> `Array[Int] ~~ Positional[Numeric]` to give False

They are different types, but one could logically be considered a "subtype" of 
the other (and would be in some programming languages).

E.g. in C#, a class Foo which takes a type parameter can define whether it 
wants to be, with regard to that parameter (using Perl 6 notation):

  covariant: Foo[Dog] ~~ Foo[Animal]
  contravariant: Foo[Animal] ~~ Foo[Dog]
  invariant: neither

(Or at least that's how I understand it, I'm just starting to learn C#.)

It appears that in Perl 6, currently only *Invariance* is supported for 
parameterized types.

Whether that is a conscious design choice ("keeping it simple"), or something 
that might be extended in the future given sufficient demand/tuits, is 
something that jnthn should be able to answer, since if I'm not mistaken he's 
done much of the Perl 6 OO work and is also a C#/Java expert.

[perl #128603] [LTA] Error on typoed named args: :foo:

[Sam S. via RT]

Same thing happens when the method call syntax is typoed to include both colon 
and and parens:

➜  say 100.base:(16)
===SORRY!===
This type (QAST::WVal) does not support positional operations

[perl #131238] [LTA] "This type cannot unbox to a native string" when not returning a `Str` from method `gist`

[Sam S. via RT]

Fair enough.

[perl #127204] [IO] for $fh.read(1024) -> $blob

[Sam S. via RT]

Unless I'm missing something, there is no bug here.

Here's how each example works:

for $fh.lines -> $line { ... }

The .lines method is only called once, and returns a lazy sequence of lines 
(represented as a Seq object). The `for` loop then iterates this sequence.

for $fh.read(1024) -> $byte { ... }

The .read method is only called once, and returns a binary buffer (represented 
as a Buf object). The `for` loop then iterates this buffer. It so happens that 
iterating a Buf iterates over its bytes, each represented as a number.

while $fh.read(1024) -> $block { ... }

The .read method is called repeatedly, once for each iteration of the while 
loop. Each iteration gets a Buf object. The while loop stops when `read` 
returns an empty Buf (which evaluates to False in boolean context).

[perl #129115] [BUG] loop doesn't allow the redeclaration of the symbol

[Sam S. via RT]

I found an old IRC discussion 
 where TimToday 
specifically confirms that the `loop` construct doesn't get an exception to the 
consistent scoping rules of `my` variables:

mikemol   for(int foo; foo < n; ++foo) { /* some code */ } ; /* use
  foo for something else; declaration from inside for() was
  still active... */

TimToady  mikemol: are you suggesting that's a bug?  Perl 6 defines
  loop that way to get consistent semantics; we only use ->
  $foo to move external declarations into a blcok

mikemol   TimToady: Yeah. Having declarations in the first part of a
  for(;;) group imply that those declarations are tied to
  that for(;;) statement. If a var needs to be survive the
  for(;;) statement, it ought to declared prior to the
  for(;;) statement. At least in languages which have strong
  relationships with C and C++ syntax. And, at least, IMO.
  It comes from seing things next to each other and expecting
  them to be closely related. It makes inductive leaps about
  behavior shorter.

TimToady  well, Perl 5 went that route, and it turns into a complete
  mess of built-ins doing one thing (sometimes) and
  non-builtins doing something else

  can't have that in an extensible language where built-ins
  and non-built-ins are supposed to work the same

mikemol   Sure.
  Perhaps the for(;;) construct is simply misnamed in Perl 6.

TimToady  it's called loop (;;)
  and we very rarely use it
  and when we do use it, it's often because we *want* the
  loop variable to survive

drake01   TimToady: How does perl6 deal with the complete mess you
  say?

TimToady  my only ever declare a variable in the surrounding block


I'm closing this ticket accordingly.

[perl #129115] [BUG] loop doesn't allow the redeclaration of the symbol

[Sam S. via RT]

Not a bug, as S04  explains:

Blocks are delimited by curlies, or by the beginning and end of
the current compilation unit (either the current file or the
current EVAL string). Unlike in Perl 5, there are (by policy) no
implicit blocks around standard control structures.

This means that the `my $foo` in your example isn't scoped to the inside of the 
loop block, but rather to the parent scope.

It's true that this can be a little annoying in the case of `loop`, where 
(unlike `while/for/if`) the outer lexical variable can't be avoided.
But that's the sacrifice that was made in return for greater consistency w.r.t. 
variable scoping.

On the bright side, it is almost never necessary to use the `loop` construct in 
Perl 6 - usually there's a better way to do the same thing with `for`.

[perl #128275] [BUG] Circular module dependency is not detected; causes program to hang

[Sam S. via RT]

Hm you're right, predeclaration doesn't seem to be the correct solution to your 
problem after all.

But this bug tracker is not the right place for Perl 6 user support, it should 
be reserved for collecting info on actual Rakudo bugs.
You should ask on the #perl6 IRC channel instead, I'm sure someone there can 
help you solve your programming problem.

As for the issue of Rakudo failing to detect the cyclic dependency and printing 
an appropriate error message for it, I've submitted a new ticket for that to 
keep it clean: [perl #128285]
I'm renaming this ticket here back to its original title, and I'm closing it.

[perl #128275] [BUG] Circular module dependency is not detected; causes program to hang

[Sam S. via RT]

Relevant info from IRC discussion:

  psch:   we did have circular module loading detection at some point... 
probably got clobbered with all the CUR work though :/
  lizmat: before, the detection lived in the nqp code, if I recall
  lizmat: now, it is the responsibility of the CUR to detect circularities
  lizmat: a start would be writing a test  :-)

[perl #128275] Visitor Pattern requires too much CPU and causes the compile error

[Sam S. via RT]

You have circular dependency between your two modules. That's not allowed.

In Bug/Acceptor.pm, instead of doing `use Bug::Visitor;`, predeclare it instead 
using `class Bug::Visitor {...}`. (Yes, those are three literal dots in the 
source code.)

---

I'm leaving the ticket open for now, because I don't know if the cyclic 
dependency should be detected by the compiler. Currently, it just keeps eating 
more and more RAM until the kernel kills the program.

Minimalist test case to reproduce the problem:

➜  echo "use B;" > A.pm
➜  echo "use A;" > B.pm
➜  perl6 -I. -e 'use A'