On Sat, 09 Dec 2017 13:19:23 -0800, elizabeth wrote:
> If that shouldn’t work, or work differently, it can be ripped
> out / replaced. If that should work, then we need to look at fixing
> -put-.
IMO it should work, considering you can't nqp::unbox_n/nqp::unbox_i Junctions
either, yet we don't have Junction-related explosions with numeric stuff.
I also found another issue: IO::Handle.print/put infiniloop in dispatch when
given a Junction.
> FWIW, I would also expect it to junct.
I started a fix down that path, but it kinda looks gross and dirty. Similar
thing would be needed
in src/core/io_operators.pm for subroutine versions. The Junctions go through
the **@foo slurpy candidates
and the explosions then happen inside optimizations, where we assume x.Str
gives an unboxable Str.
Is there a better way? Here's my thing:
2017.11.50 zoffix@VirtualBox~/CPANPRC/rakudo (master)$ gd
diff --git a/src/core/IO/Handle.pm b/src/core/IO/Handle.pm
index 55ff911..0303047 100644
--- a/src/core/IO/Handle.pm
+++ b/src/core/IO/Handle.pm
@@ -652,6 +652,11 @@ my class IO::Handle {
multi method print(IO::Handle:D: **@list is raw --> True) { # is raw gives
List, which is cheaper
self.print(@list.join);
}
+ multi method print(IO::Handle:D: Junction \j --> True) {
+ # junct the Junction. Without this candidate, we'd go through the
+ # **@list slurpy candidate and dispatch infiniloop.
+ -> Any \el { self.print: el }(j)
+ }
proto method put(|) {*}
multi method put(IO::Handle:D: Str:D \x --> True) {
@@ -662,6 +667,11 @@ my class IO::Handle {
multi method put(IO::Handle:D: **@list is raw --> True) { # is raw gives
List, which is cheaper
self.put(@list.join);
}
+ multi method put(IO::Handle:D: Junction \j --> True) {
+ # junct the Junction. Without this candidate, we'd go through the
+ # **@list slurpy candidate and dispatch infiniloop.
+ -> Any \el { self.put: el }(j)
+ }
multi method say(IO::Handle:D: Str:D $x --> True) {
$!decoder or die X::IO::BinaryMode.new(:trying<say>);