Re: Problem defining factorial operator in .rakumod file

[Brian Duggan]

On Friday, October 14, Bruce Gray wrote: 
> because the `~` tilde character is not special to Raku.
> Instead of:
> use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
> , you need either of these:
> use lib "%*ENV/Documents/myRaku/gitHub/SequenceHelper/lib";
> use lib  %*ENV ~ '/Documents/myRaku/gitHub/SequenceHelper/lib';

There is also $*HOME, so this could be written as:

   use lib $*HOME.child('Documents/myRaku/gitHub/SequenceHelper/lib')

Brian

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 6:03 PM, Ralph Mellor wrote:

On Fri, Oct 14, 2022 at 10:59 PM Joseph Polanik  wrote:

Update: ... all methods are reporting correct results.

Thanks for the help.

Good to see resolution of problems. :)

Is everything now resolved or are some things still outstanding?

--
love, raiph


I believe that my problem is resolved; so, you were right in that it had 
nothing to do with the problems with the REPL.


Regards,

Joe

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 5:48 PM, Bruce Gray wrote:

On Oct 14, 2022, at 3:23 PM, Joseph Polanik  wrote:
The script Run/run_SequenceHelper.raku contains only the following lines

use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
use SequenceHelper :ALL;

--snip--

A possible piece of the puzzle is that your `use` line is silently failing,
because the `~` tilde character is not special to Raku.
Instead of:
 use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
, you need either of these:
 use lib "%*ENV/Documents/myRaku/gitHub/SequenceHelper/lib";
 use lib  %*ENV ~ '/Documents/myRaku/gitHub/SequenceHelper/lib';

Therefore, the module you have been testing might not be the one you thought 
you were testing.

To demonstrate, notice that in the error message below, the first search path contains 
the literal "Junk/~".
 cd ~/Junk
 raku -e 'use lib "~/FakeDir"; use FakeModule;'
 ===SORRY!=== Error while compiling -e
 Could not find FakeModule in:
 file#/Users/bruce_pro/Junk/~/FakeDir
 ...


Bruce and Vadim. I've removed the tilde as a precaution.

Thanks for the comment.

Joe

Re: Problem defining factorial operator in .rakumod file

[Ralph Mellor]

On Fri, Oct 14, 2022 at 10:59 PM Joseph Polanik  wrote:
>
> Update: ... all methods are reporting correct results.
>
> Thanks for the help.

Good to see resolution of problems. :)

Is everything now resolved or are some things still outstanding?

--
love, raiph

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

Update: I was missing a couple of commas. Now all methods are reporting 
correct results.


raku --ll-exception 
-I/home/jpolanik/Documents/myRaku/gitHub/SequenceHelper/lib/ 
Run/run_SequenceHelper.raku


Invoke factorial operator
120

Invoke factorial sub
120

Invoke double factorial operator
15

Invoke is-palindrome
True

Invoke genSeq_IndexOps
[3 14 70 368 2002]

Invoke genSeq_ArrayOps
[0 1 1 2 3 5 8 13 21 34 55]

Thanks for the help.

Joe

Re: Problem defining factorial operator in .rakumod file

[Bruce Gray]

> On Oct 14, 2022, at 3:23 PM, Joseph Polanik  wrote:
> 
>> The script Run/run_SequenceHelper.raku contains only the following lines
>>> use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
>>> use SequenceHelper :ALL;

--snip--

A possible piece of the puzzle is that your `use` line is silently failing,
because the `~` tilde character is not special to Raku.
Instead of:
use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
, you need either of these:
use lib "%*ENV/Documents/myRaku/gitHub/SequenceHelper/lib";
use lib  %*ENV ~ '/Documents/myRaku/gitHub/SequenceHelper/lib';

Therefore, the module you have been testing might not be the one you thought 
you were testing.

To demonstrate, notice that in the error message below, the first search path 
contains the literal "Junk/~".
cd ~/Junk
raku -e 'use lib "~/FakeDir"; use FakeModule;'
===SORRY!=== Error while compiling -e
Could not find FakeModule in:
file#/Users/bruce_pro/Junk/~/FakeDir
...


-- 
Hope this helps,
Bruce Gray (Util of PerlMonks)

Re: Problem defining factorial operator in .rakumod file

[Vadim Belman]

I like the way you use ~ in `use lib '~/...';`. Though it doesn't work as 
expected. But it's nice! :D

Best regards,
Vadim Belman

> On Oct 14, 2022, at 4:05 PM, Joseph Polanik  wrote:
> 
> On 10/14/22 3:38 PM, Elizabeth Mattijsen wrote: 
>>> On 14 Oct 2022, at 21:15, Joseph Polanik  
>>>  wrote: 
>>> Actually, I did create a factorial() sub, but that didn't get me out of my 
>>> present predicament. It works as expected when invoked from the command 
>>> line. However, when invoked from a test script (or the REPL) the error 
>>> message is "Undeclared routine". 
>> Could you please run that case with: 
>> 
>> $ raku --ll-exception -Idir-with-module test-script 
>> 
>> and post the output? 
> $ raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku 
> Undeclared routine: 
> factorial used at line 23 
> 
>at SETTING::src/core.c/Exception.pm6:64 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw)
>  
>  from gen/moar/Grammar.nqp:4517 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:cry_sorrows)
>  
>  from gen/moar/Grammar.nqp:838 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit)
>  
>  from gen/moar/Grammar.nqp:553 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:TOP)
>  
>  from gen/moar/stage2/QRegex.nqp:2267 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/QRegex.moarvm:parse) 
>  from gen/moar/stage2/NQPHLL.nqp:2301 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:parse) 
>  from gen/moar/stage2/NQPHLL.nqp:2217 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:execute_stage)
>  
>  from gen/moar/stage2/NQPHLL.nqp:2252 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:run) 
>  from gen/moar/stage2/NQPHLL.nqp:2248 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:) 
>  from gen/moar/stage2/NQPHLL.nqp:2244 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:compile) 
>  from gen/moar/stage2/NQPHLL.nqp:1919 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:eval) 
>  from gen/moar/stage2/NQPHLL.nqp:2154 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:evalfiles)
>  
>  from gen/moar/stage2/NQPHLL.nqp:2114 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval)
>  
>  from gen/moar/Compiler.nqp:105 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval)
>  
>  from gen/moar/stage2/NQPHLL.nqp:2039 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_line)
>  
>  from gen/moar/rakudo.nqp:140 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:MAIN)
>  
>  from gen/moar/rakudo.nqp:1 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
>  
>  from :1 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
>  
>  from :1 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
>  
> 
> The script Run/run_SequenceHelper.raku contains only the following lines 
> 
> use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib'; 
> use SequenceHelper :ALL; 
> say factorial(5); 
> 
> Thanks for looking into this. 
> 
> Joe 
> 
> 

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 4:53 PM, Elizabeth Mattijsen wrote:

raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku
I hope you changed "dir-with-module" by the actual directory name.


I didn't. My bad. Now, four subs are producing correct results

raku --ll-exception 
-I/home/jpolanik/Documents/myRaku/gitHub/SequenceHelper/lib/ 
Run/run_SequenceHelper.raku


Invoke factorial operator
120

Invoke factorial sub
120

Invoke double factorial operator
15

Invoke is-palindrome
True

The other two methods, genSeq_IndexOps and  genSeq_ArrayOps, are 
producing errors:


raku --ll-exception 
-I/home/jpolanik/Documents/myRaku/gitHub/SequenceHelper/lib/ 
Run/run_SequenceHelper.raku

Two terms in a row across lines (missing semicolon or comma?)
   at SETTING::src/core.c/Exception.pm6:64 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw)
 from gen/moar/World.nqp:5447 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/World.moarvm:throw)
 from gen/moar/Grammar.nqp:295 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:typed_panic)
 from gen/moar/Grammar.nqp:991 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:eat_terminator)
 from gen/moar/Grammar.nqp:890 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:statementlist)
 from gen/moar/stage2/NQPHLL.nqp:1471 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:LANG)
 from gen/moar/Grammar.nqp:1342 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:FOREIGN_LANG)
 from gen/moar/Grammar.nqp:838 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit)
 from gen/moar/Grammar.nqp:553 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:TOP)
 from gen/moar/stage2/QRegex.nqp:2267 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/QRegex.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2301 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2217 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:execute_stage)
 from gen/moar/stage2/NQPHLL.nqp:2252 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:run)
 from gen/moar/stage2/NQPHLL.nqp:2248 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:2244 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:compile)
 from gen/moar/stage2/NQPHLL.nqp:1919 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:2154 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:2114 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval)
 from gen/moar/Compiler.nqp:105 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:2039 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/rakudo.nqp:140 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/rakudo.nqp:1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)


I'll keep playing with those two malfunctions.

Joe








Do you happen to have a subroutine called "EXPORT" in the module?


No

Re: Problem defining factorial operator in .rakumod file

[Elizabeth Mattijsen]

> On 14 Oct 2022, at 22:23, Joseph Polanik  wrote:
> 
> On 10/14/22 4:15 PM, Elizabeth Mattijsen wrote:
> 
>> The script Run/run_SequenceHelper.raku contains only the following lines
>>> use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
>>> use SequenceHelper :ALL;
>> OOC, what happens if you remove the :ALL here?
> 
> No change that I can see:
> 
> raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku

I hope you changed "dir-with-module" by the actual directory name.

> Undeclared routine:
> factorial used at line 23

Do you happen to have a subroutine called "EXPORT" in the module?

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 4:15 PM, Elizabeth Mattijsen wrote:


The script Run/run_SequenceHelper.raku contains only the following lines

use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
use SequenceHelper :ALL;

OOC, what happens if you remove the :ALL here?


No change that I can see:

raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku
Undeclared routine:
    factorial used at line 23

   at SETTING::src/core.c/Exception.pm6:64 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw)
 from gen/moar/Grammar.nqp:4517 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:cry_sorrows)
 from gen/moar/Grammar.nqp:838 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit)
 from gen/moar/Grammar.nqp:553 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:TOP)
 from gen/moar/stage2/QRegex.nqp:2267 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/QRegex.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2301 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2217 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:execute_stage)
 from gen/moar/stage2/NQPHLL.nqp:2252 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:run)
 from gen/moar/stage2/NQPHLL.nqp:2248 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:2244 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:compile)
 from gen/moar/stage2/NQPHLL.nqp:1919 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:2154 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:evalfiles)
 from gen/moar/stage2/NQPHLL.nqp:2114 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval)
 from gen/moar/Compiler.nqp:105 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval)
 from gen/moar/stage2/NQPHLL.nqp:2039 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_line)
 from gen/moar/rakudo.nqp:140 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:MAIN)
 from gen/moar/rakudo.nqp:1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)
 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:)


Joe

Re: Problem defining factorial operator in .rakumod file

[Elizabeth Mattijsen]

> On 14 Oct 2022, at 22:05, Joseph Polanik  wrote:
> 
> On 10/14/22 3:38 PM, Elizabeth Mattijsen wrote: 
>>> On 14 Oct 2022, at 21:15, Joseph Polanik  wrote: 
>>> Actually, I did create a factorial() sub, but that didn't get me out of my 
>>> present predicament. It works as expected when invoked from the command 
>>> line. However, when invoked from a test script (or the REPL) the error 
>>> message is "Undeclared routine". 
>> Could you please run that case with: 
>> 
>> $ raku --ll-exception -Idir-with-module test-script 
>> 
>> and post the output? 
> $ raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku 
> Undeclared routine: 
> factorial used at line 23 
> 
>at SETTING::src/core.c/Exception.pm6:64 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw)
>  
>  from gen/moar/Grammar.nqp:4517 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:cry_sorrows)
>  
>  from gen/moar/Grammar.nqp:838 
> (/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit)

So, this is really the static optimizer complaining about the fact that 
"factorial" did not actually got exported.


> The script Run/run_SequenceHelper.raku contains only the following lines 
> 
> use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib'; 
> use SequenceHelper :ALL;

OOC, what happens if you remove the :ALL here?


Liz

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 3:38 PM, Elizabeth Mattijsen wrote:

On 14 Oct 2022, at 21:15, Joseph Polanik  wrote:
Actually, I did create a factorial() sub, but that didn't get me out 
of my present predicament. It works as expected when invoked from the 
command line. However, when invoked from a test script (or the REPL) 
the error message is "Undeclared routine".

Could you please run that case with:

$ raku --ll-exception -Idir-with-module test-script

and post the output?

$ raku --ll-exception -Idir-with-module Run/run_SequenceHelper.raku
Undeclared routine:
    factorial used at line 23

   at SETTING::src/core.c/Exception.pm6:64 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/CORE.c.setting.moarvm:throw) 

 from gen/moar/Grammar.nqp:4517 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:cry_sorrows) 

 from gen/moar/Grammar.nqp:838 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:comp_unit) 

 from gen/moar/Grammar.nqp:553 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Grammar.moarvm:TOP) 

 from gen/moar/stage2/QRegex.nqp:2267 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/QRegex.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2301 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:parse)
 from gen/moar/stage2/NQPHLL.nqp:2217 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:execute_stage) 

 from gen/moar/stage2/NQPHLL.nqp:2252 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:run)
 from gen/moar/stage2/NQPHLL.nqp:2248 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:)
 from gen/moar/stage2/NQPHLL.nqp:2244 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:compile) 

 from gen/moar/stage2/NQPHLL.nqp:1919 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:eval)
 from gen/moar/stage2/NQPHLL.nqp:2154 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:evalfiles) 

 from gen/moar/stage2/NQPHLL.nqp:2114 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_eval) 

 from gen/moar/Compiler.nqp:105 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/lib/Perl6/Compiler.moarvm:command_eval) 

 from gen/moar/stage2/NQPHLL.nqp:2039 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/nqp/lib/NQPHLL.moarvm:command_line) 

 from gen/moar/rakudo.nqp:140 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:MAIN) 

 from gen/moar/rakudo.nqp:1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) 

 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) 

 from :1 
(/home/jpolanik/rakudo-2022.07-01/bin/../share/perl6/runtime/perl6.moarvm:) 



The script Run/run_SequenceHelper.raku contains only the following lines

use lib '~/Documents/myRaku/gitHub/SequenceHelper/lib';
use SequenceHelper :ALL;
say factorial(5);

Thanks for looking into this.

Joe

Re: Problem defining factorial operator in .rakumod file

[Elizabeth Mattijsen]

> On 14 Oct 2022, at 21:15, Joseph Polanik  wrote:
> Actually, I did create a factorial() sub, but that didn't get me out of my 
> present predicament. It works as expected when invoked from the command line. 
> However, when invoked from a test script (or the REPL) the error message is 
> "Undeclared routine".

Could you please run that case with:

$ raku --ll-exception -Idir-with-module test-script

and post the output?


Liz

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 11:39 AM, Parrot Raiser wrote:

The cause of the problem may well need to be fixed for other reasons,
but re-purposing an almost universal operator like "!" ("not") sounds
like a thoroughly bad idea, the route to non-standard code.

If you must have a factorial operator, what's wrong with defining "Fact"?


! meaning 'not' is a prefix operator. ! meaning factorial is a postfix 
operator. So, the two can co-exist.


Actually, I did create a factorial() sub, but that didn't get me out of 
my present predicament. It works as expected when invoked from the 
command line. However, when invoked from a test script (or the REPL) the 
error message is "Undeclared routine".


Regards,

Joe

Re: Problem defining factorial operator in .rakumod file

[Elizabeth Mattijsen]

> On 14 Oct 2022, at 20:35, Joseph Polanik  wrote:
> Each of these results is correct. So, the problem remains that some subs are 
> not found when invoked either from a test script or from the REPL.
> 
> Is there some cache that I must clear when changing a .rakumod file to 
> prevent my system from hanging on to old material?

No, that's the whole point of `use lib "foo"`: it will checksum all files in 
"foo" *and* its subdirectoroies, and will recompile if *any* file changed.


Liz

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/14/22 4:32 AM, Elizabeth Mattijsen wrote:

I cannot reproduce:

% cat lib/A.rakumod
sub postfix: ($n) is export {
 when $n == 0 {return 1}
 default {$n * ($n - 1)!}
}
% raku -e 'use lib "lib"; use A; say 42!'
14050061177528798985431426062445115699363840


Very helpful. I have 6 subs in my module and all 6 work correctly when 
invoked from the system command line.


# Verify version
raku -e 'use lib "lib"; use SequenceHelper; say ver()';
# v0.0.1

# Verify factorial operator
raku -e 'use lib "lib"; use SequenceHelper; say 42!';
# 140500611775287989854314260624451156993638400000

# Verify double factorial operator
raku -e 'use lib "lib"; use SequenceHelper; say 5!!';
# 15

# Generate a sequence using genSeq_IndexOps
raku -e 'use lib "lib"; use SequenceHelper; say genSeq_IndexOps(5, -> $x 
{3**$x + 5**$x + 6**$x})';

# [3 14 70 368 2002]

# Generate a sequence using genSeq_ArrayOps
raku -e 'use lib "lib"; use SequenceHelper; say genSeq_ArrayOps(11, -> 
$x, @z {@z[$x-1] + @z[$x-2]}, <0 1>)';

# [0 1 1 2 3 5 8 13 21 34 55]

#Verify Palindrome detector
raku -e 'use lib "lib"; use SequenceHelper; say is-palindrome("noon")';

#True

Each of these results is correct. So, the problem remains that some subs 
are not found when invoked either from a test script or from the REPL.


Is there some cache that I must clear when changing a .rakumod file to 
prevent my system from hanging on to old material?


Regards,

Joe

Re: Problem defining factorial operator in .rakumod file

[Parrot Raiser]

The cause of the problem may well need to be fixed for other reasons,
but re-purposing an almost universal operator like "!" ("not") sounds
like a thoroughly bad idea, the route to non-standard code.

If you must have a factorial operator, what's wrong with defining "Fact"?

On 10/14/22, Elizabeth Mattijsen  wrote:
> I cannot reproduce:
>
> % cat lib/A.rakumod
> sub postfix: ($n) is export {
> when $n == 0 {return 1}
> default {$n * ($n - 1)!}
> }
> % raku -e 'use lib "lib"; use A; say 42!'
> 14050061177528798985431426062445115699363840
> % raku -v
> Welcome to Rakudo™ v2022.07-64-gce1af0fa0.
> Implementing the Raku® Programming Language v6.d.
> Built on MoarVM version 2022.07-16-g3ae8a31c1.
>
>> On 14 Oct 2022, at 05:30, Joseph Polanik  wrote:
>>
>>
>> On 10/13/22 9:19 PM, Ralph Mellor wrote:
>>> On Fri, Oct 14, 2022 at 12:37 AM Joseph Polanik 
>>> wrote:
>>>> I am trying to define '!' as the factorial operator. The following
>>>> works
>>>> in a .raku script file:
>>>>
>>>>sub postfix: ($n) is export {
>>>>  when $n == 0 {return 1}
>>>>  default {$n * ($n - 1)!}
>>>>}
>>>>
>>>> However when I tried to move this sub to a .rakumod file,
>>>> it produces an error: Negation metaoperator not followed
>>>> by valid infix.
>>> That's because Raku isn't picking up your `sub`.
>>>
>>> I don't know why. It works for me. (v2022.02)
>>>
>>> Are you sure you're `use`ing it correctly and the `sub`
>>> has the `is export`?
>>
>> Yes, the sub that defines the factorial operator is marked with 'is
>> export' and the script that invokes my module (SequenceHelper) has a 'use'
>> statement.
>>
>> The script is able to invoke other methods marked 'is export'; for
>> example, the simple ver() and a method that generates an integer
>> sequence:
>>
>>   sub genSeq_IndexOps($limit, $f) is export {
>> my @a = ();
>> for (0...^$limit) -> $n {
>>   @a.push($f($n));
>> }
>> return @a;
>>   }
>>
>> So the module is being found and used. It seems as if certain methods
>> aren't being found.
>>
>> I am not convinced that the problem I'm having is unrelated to the issue
>> raised concerning the REPL. When I use the REPL, the results are the
>> same.
>>
>> [0] > use SequenceHelper;
>> Nil
>> [1] > say ver();
>> v0.0.1
>> [1] > say 4!;
>> ===SORRY!=== Error while compiling:
>> Negation metaoperator not followed by valid infix
>> [1] > put genSeq_IndexOps(15, -> $x {3**$x + 5**$x + 6**$x});
>> 3 14 70 368 2002 11144 63010 360248 2076802 12050504 70290850 411802328
>> 2421454402 14282991464 84472462690
>>
>> Regards,
>>
>> Joe
>>
>
>

Re: Problem defining factorial operator in .rakumod file

[Elizabeth Mattijsen]

I cannot reproduce:

% cat lib/A.rakumod 
sub postfix: ($n) is export {
when $n == 0 {return 1}
default {$n * ($n - 1)!}
}
% raku -e 'use lib "lib"; use A; say 42!'
14050061177528798985431426062445115699363840
% raku -v
Welcome to Rakudo™ v2022.07-64-gce1af0fa0.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2022.07-16-g3ae8a31c1.

> On 14 Oct 2022, at 05:30, Joseph Polanik  wrote:
> 
> 
> On 10/13/22 9:19 PM, Ralph Mellor wrote:
>> On Fri, Oct 14, 2022 at 12:37 AM Joseph Polanik  wrote:
>>> I am trying to define '!' as the factorial operator. The following works
>>> in a .raku script file:
>>> 
>>>sub postfix: ($n) is export {
>>>  when $n == 0 {return 1}
>>>  default {$n * ($n - 1)!}
>>>}
>>> 
>>> However when I tried to move this sub to a .rakumod file,
>>> it produces an error: Negation metaoperator not followed
>>> by valid infix.
>> That's because Raku isn't picking up your `sub`.
>> 
>> I don't know why. It works for me. (v2022.02)
>> 
>> Are you sure you're `use`ing it correctly and the `sub`
>> has the `is export`?
> 
> Yes, the sub that defines the factorial operator is marked with 'is export' 
> and the script that invokes my module (SequenceHelper) has a 'use' statement.
> 
> The script is able to invoke other methods marked 'is export'; for example, 
> the simple ver() and a method that generates an integer sequence:
> 
>   sub genSeq_IndexOps($limit, $f) is export {
> my @a = ();
> for (0...^$limit) -> $n {
>   @a.push($f($n));
> }
> return @a;
>   }
> 
> So the module is being found and used. It seems as if certain methods aren't 
> being found.
> 
> I am not convinced that the problem I'm having is unrelated to the issue 
> raised concerning the REPL. When I use the REPL, the results are the same.
> 
> [0] > use SequenceHelper;
> Nil
> [1] > say ver();
> v0.0.1
> [1] > say 4!;
> ===SORRY!=== Error while compiling:
> Negation metaoperator not followed by valid infix
> [1] > put genSeq_IndexOps(15, -> $x {3**$x + 5**$x + 6**$x});
> 3 14 70 368 2002 11144 63010 360248 2076802 12050504 70290850 411802328 
> 2421454402 14282991464 84472462690
> 
> Regards,
> 
> Joe
> 

Re: Problem defining factorial operator in .rakumod file

[Ralph Mellor]

On Fri, Oct 14, 2022 at 4:30 AM Joseph Polanik  wrote:
>
> > It works for me. (v2022.02)
>
> When I use the REPL, the results are the same.

The results are the same for ALL of us, for ALL Rakudo versions.
Try the program 42!; Note how the error message is the same.
The results are the same for ALL of us, for ALL Rakudo versions.

Your scenario does not involve the REPL. And it does not occur on
the Rakudo versions I've tried it on even though those versions do
have the REPL bug.

Your scenario is different. Same symptoms. Different root cause.

--
love, raiph

Re: Problem defining factorial operator in .rakumod file

[Joseph Polanik]

On 10/13/22 9:19 PM, Ralph Mellor wrote:

On Fri, Oct 14, 2022 at 12:37 AM Joseph Polanik  wrote:

I am trying to define '!' as the factorial operator. The following works
in a .raku script file:

sub postfix: ($n) is export {
  when $n == 0 {return 1}
  default {$n * ($n - 1)!}
}

However when I tried to move this sub to a .rakumod file,
it produces an error: Negation metaoperator not followed
by valid infix.

That's because Raku isn't picking up your `sub`.

I don't know why. It works for me. (v2022.02)

Are you sure you're `use`ing it correctly and the `sub`
has the `is export`?


Yes, the sub that defines the factorial operator is marked with 'is 
export' and the script that invokes my module (SequenceHelper) has a 
'use' statement.


The script is able to invoke other methods marked 'is export'; for 
example, the simple ver() and a method that generates an integer sequence:


  sub genSeq_IndexOps($limit, $f) is export {
    my @a = ();
    for (0...^$limit) -> $n {
  @a.push($f($n));
    }
    return @a;
  }

So the module is being found and used. It seems as if certain methods 
aren't being found.


I am not convinced that the problem I'm having is unrelated to the issue 
raised concerning the REPL. When I use the REPL, the results are the same.


[0] > use SequenceHelper;
Nil
[1] > say ver();
v0.0.1
[1] > say 4!;
===SORRY!=== Error while compiling:
Negation metaoperator not followed by valid infix
[1] > put genSeq_IndexOps(15, -> $x {3**$x + 5**$x + 6**$x});
3 14 70 368 2002 11144 63010 360248 2076802 12050504 70290850 411802328 
2421454402 14282991464 84472462690


Regards,

Joe

Re: Problem defining factorial operator in .rakumod file

[Ralph Mellor]

On Fri, Oct 14, 2022 at 12:37 AM Joseph Polanik  wrote:
>
> I am trying to define '!' as the factorial operator. The following works
> in a .raku script file:
>
>sub postfix: ($n) is export {
>  when $n == 0 {return 1}
>  default {$n * ($n - 1)!}
>}
>
> However when I tried to move this sub to a .rakumod file,
> it produces an error: Negation metaoperator not followed
> by valid infix.

That's because Raku isn't picking up your `sub`.

I don't know why. It works for me. (v2022.02)

Are you sure you're `use`ing it correctly and the `sub`
has the `is export`?

Can anyone else reproduce Joseph's problem?

> It turns out that this is a known issue, #3774

No, that's specific to the REPL.

The error message is the same; the common thing between
the two cases is that Raku is unaware the postfix has been
defined. The REPL problem is known. But the problem you're
sharing is unrelated to the REPL problem.

--
love, raiph

Problem defining factorial operator in .rakumod file

[Joseph Polanik]

I am trying to define '!' as the factorial operator. The following works 
in a .raku script file:


  sub postfix: ($n) is export {
    when $n == 0 {return 1}
    default {$n * ($n - 1)!}
  }

However when I tried to move this sub to a .rakumod file, it produces an 
error: Negation metaoperator not followed by valid infix.


It turns out that this is a known issue, #3774,  with rakudo first 
logged (AFAIK) in July 2020. Until this is fixed in some future release 
of Rakudo, is there a workaround for this?


Note: I am using Rakudo v2022.07 on Ubuntu 20.04.5.

Thanks,

Joe

Re: The ,= operator

[Ralph Mellor]

> > @fib[1, 5, 10..15, 20]
> (1 8 (89 144 233 377 610 987) 10946)
>  ^
>
> Why???

As Joe noted in his last email:

> remember, back in perl-land the default behavior is to flatten,
> in raku ... by default [raku is] oriented toward building up
> complex structures like arrays of arrays.

So Raku does *not* flatten the `10..15`, yielding the result you see.



You may have been thrown by seeing that, with `@fib[1..5]`, the
range *is* flattened. That's because of the "single argument rule".
This is an important Raku concept.

In brief, in contexts that are inherently "listy", not "scalar", Raku
takes the view that if it's given a *single* thing that is itself listy,
Raku should treat that thing as the list of elements it contains.
Whereas, if it's given a list of things, then it just accepts that list
as is.

Thus `@fib[1..5]` treats the `1..5` as 5 elements, i.e. flattening
the range, but treats `@fib[1, 5, 10..15, 20]` as 4 elements, with
the third being a nested 6 element list that it does *not* flatten.



Perhaps you want the whole lot flattened.

Quoting Joe again:

> arrays don't flatten unless you do something to make it happen

One option:

@fib[flat 1, 5, 10..15, 20]
> (1 8 89 144 233 377 610 987 10946)

love, raiph

Re: The ,= operator

[Aureliano Guedes]

I didn't understood

> my @fib = 1,1, * + * … *;
[...]
> @fib[1]
1
> @fib[5]
8
> @fib[1..5]
(1 2 3 5 8)


*> @fib[1, 5, 10..15, 20](1 8 (89 144 233 377 610 987) 10946)*
* ^*

Why???



On Mon, Dec 7, 2020 at 2:27 AM William Michels via perl6-users <
perl6-us...@perl.org> wrote:

>
>
> On Sun, Nov 29, 2020 at 6:38 PM Ralph Mellor 
> wrote:
>
>> > Zen slicing as a possible way of 'de-containerizing' :
>> > https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>>
>> A zen-slice only affects the single reference it's applied to.
>>
>> And it is a no op when applied to anything other than a `Scalar`.
>>
>> So it'll have no effect when applied directly to an array, list, hash,
>> or other non `Scalar`.
>>
>> Perhaps you're thinking "decontainerizing" does something other
>> than what it does? It's really a very simple operation. An analogy
>> is having a bunch of folk, some of whom always go by their legal
>> name, but others who sometimes go by their nickname. And let's
>> say there's an operation called "use legal name". When applied
>> to a nickname it yields the corresponding legal name. But when
>> applied to a legal name it just yields that name, i.e. it's a no op.
>>
>> That's all that decont does, except the analog to a nickname is
>> a `Scalar`, and the analog to a legal name is anything else.
>>
>> > Even if the ",=" postfix operator were to gain this ability on non-hash
>> > objects, then hash-objects would be special-cased in **not** requiring
>> > a Zen-sliced decontainerized object on the LHS, so people would have
>> > to consider that outcome.
>>
>> I think the focus on `,=`.is really unfortunate, because the real issue is
>> just about what `=` does with a non-`Scalar` on its LHS and a list of
>> values on its RHS. It's really got nothing whatsoever to do with `,`.
>>
>> It just depends on the type of non-`Scalar` on the LHS of `=`.
>>
>> Look what happens without not a comma in sight:
>>
>> my %hash = do for ^1 { %hash }
>> say %hash; # {}
>>
>> If it's a hash,, the only sensible thing to do with a list of values that
>> may
>> each be a pair, or a list of pairs, or an array of pairs, or a hash of
>> pairs,
>> is to flatten and concatenate all the individual pairs into the hash.
>>
>> my @array = do for ^1 { @array }
>> say @array; # (\Array_73652568 = [Array_73652568])
>>
>> But if it's an array, the sensible thing to do is to *not* flatten by
>> default.
>>
>
>
> This topic was a subject of discussion during our (SF_Perl) Raku Meetup
> Group today. We reviewed the three URL references below. One member of our
> Meetup went throught the 2017 Advent Calendar reference extensively
> (hopefully we'll see a post on that). Afterwards, I played a bit with
> indexing constructs. Posting these for posterity's sake:
>
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices
> https://docs.raku.org/language/glossary#index-entry-decont
> https://perl6advent.wordpress.com/2017/12/02/#theoneandonly
>
> user@mbook:~$ raku
> Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
> Implementing the 퐑퐚퐤퐮™ programming language v6.d.
> Built on MoarVM version 2020.10.
>
> You may want to `zef install Readline` or `zef install Linenoise` or use
> rlwrap for a line editor
>
> To exit type 'exit' or '^D'
> > my %hash = do for ^1 { %hash }
> {}
> > my %hash2 = do for ^1 { %hash2<> }
> {}
> > my %hash3 = do for ^1 { %hash3<*> }
> Odd number of elements found where hash initializer expected:
> Only saw 1 element
>   in block  at  line 1
>
> > my @array = do for ^1 { @array }
> (\Array_140587615723064 = [Array_140587615723064])
> > my @array2 = do for ^1 { @array2[] }
> (\Array_140587615723904 = [Array_140587615723904])
> > my @array3 = do for ^1 { @array3[*] }
> [()]
>
> Best Regards, Bill.
>
>

-- 
Aureliano Guedes
skype: aureliano.guedes
contato:  (11) 94292-6110
whatsapp +5511942926110

Re: The ,= operator

[William Michels via perl6-users]

On Sun, Nov 29, 2020 at 6:38 PM Ralph Mellor 
wrote:

> > Zen slicing as a possible way of 'de-containerizing' :
> > https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>
> A zen-slice only affects the single reference it's applied to.
>
> And it is a no op when applied to anything other than a `Scalar`.
>
> So it'll have no effect when applied directly to an array, list, hash,
> or other non `Scalar`.
>
> Perhaps you're thinking "decontainerizing" does something other
> than what it does? It's really a very simple operation. An analogy
> is having a bunch of folk, some of whom always go by their legal
> name, but others who sometimes go by their nickname. And let's
> say there's an operation called "use legal name". When applied
> to a nickname it yields the corresponding legal name. But when
> applied to a legal name it just yields that name, i.e. it's a no op.
>
> That's all that decont does, except the analog to a nickname is
> a `Scalar`, and the analog to a legal name is anything else.
>
> > Even if the ",=" postfix operator were to gain this ability on non-hash
> > objects, then hash-objects would be special-cased in **not** requiring
> > a Zen-sliced decontainerized object on the LHS, so people would have
> > to consider that outcome.
>
> I think the focus on `,=`.is really unfortunate, because the real issue is
> just about what `=` does with a non-`Scalar` on its LHS and a list of
> values on its RHS. It's really got nothing whatsoever to do with `,`.
>
> It just depends on the type of non-`Scalar` on the LHS of `=`.
>
> Look what happens without not a comma in sight:
>
> my %hash = do for ^1 { %hash }
> say %hash; # {}
>
> If it's a hash,, the only sensible thing to do with a list of values that
> may
> each be a pair, or a list of pairs, or an array of pairs, or a hash of
> pairs,
> is to flatten and concatenate all the individual pairs into the hash.
>
> my @array = do for ^1 { @array }
> say @array; # (\Array_73652568 = [Array_73652568])
>
> But if it's an array, the sensible thing to do is to *not* flatten by
> default.
>


This topic was a subject of discussion during our (SF_Perl) Raku Meetup
Group today. We reviewed the three URL references below. One member of our
Meetup went throught the 2017 Advent Calendar reference extensively
(hopefully we'll see a post on that). Afterwards, I played a bit with
indexing constructs. Posting these for posterity's sake:

https://docs.raku.org/language/subscripts#index-entry-Zen_slices
https://docs.raku.org/language/glossary#index-entry-decont
https://perl6advent.wordpress.com/2017/12/02/#theoneandonly

user@mbook:~$ raku
Welcome to 퐑퐚퐤퐮퐝퐨™ v2020.10.
Implementing the 퐑퐚퐤퐮™ programming language v6.d.
Built on MoarVM version 2020.10.

You may want to `zef install Readline` or `zef install Linenoise` or use
rlwrap for a line editor

To exit type 'exit' or '^D'
> my %hash = do for ^1 { %hash }
{}
> my %hash2 = do for ^1 { %hash2<> }
{}
> my %hash3 = do for ^1 { %hash3<*> }
Odd number of elements found where hash initializer expected:
Only saw 1 element
  in block  at  line 1

> my @array = do for ^1 { @array }
(\Array_140587615723064 = [Array_140587615723064])
> my @array2 = do for ^1 { @array2[] }
(\Array_140587615723904 = [Array_140587615723904])
> my @array3 = do for ^1 { @array3[*] }
[()]

Best Regards, Bill.

Re: The ,= operator

[Joseph Brenner]

ToddAndMargo via perl6-users  wrote:

> I am a little late to this conversation, but `,=`
> looks a lot like `push` to me.

Yes that was my first impression, if you read ahead a bit in the
discussion you'll see it explained.

In summary: the = shortcuts all work in a precisely parallel way, so

@r ,= 'd';

is the same as:

@r = @r , 'd';

And remember, back in perl-land the default behavior is to flatten,
but in raku arrays don't flatten unless you do something to make it
happen-- by default it's oriented toward building up complex
structures like arrays of arrays.   So with this construct, you end up
with the array containing a circular reference to itself in the first
location, which is highly unlikely to be something you want.

Hashes, on the other hand, *don't* tend to flatten by default, so ,=
does something useful with them.

If you wanted to just add an element to the end, you could do one of these:

@r.append('d');
@r = | @r, 'd';
@r.push('d');

The trouble with that last one though, is you may find it surprising
if you're pushing more than a single element, this will get you an
array inside an array:

@r.push(@a);

This on the other hand, behaves just like an @r.append(@a) would:
@r.push(| @a);

Re: The ,= operator

[ToddAndMargo via perl6-users]

Hi All,

I am a little late to this conversation, but `,=`
looks a lot like `push` to me.   Am I missing
something?

-T

Re: The ,= operator

[Joseph Brenner]

William Michels  wrote:

> Joe, what would you expect the code below to produce?

>  %h<> ,= c => 3;
>  @a[] ,= 'd';

Well *I* expect it to error out, but that's my p5 brain talking.

The Raku approach is if you ask for nothing it gives you
everything, so an empty index like that essentially doesn't
change anything.

And in any case, there are limits to how much it's worth
thinking about this case, because there are other ways to do what
I thought ,= would do on an array:

my @a = ;
@a.append('d');
say @a; # [a b c d ]

As Ralph Mellor was suggesting, .append is indeed closer to what I was
thinking than .push.
When you're trying to add multiple elements, the .append method
appends the list to the list in the first array, but .push treats a
given array as a single element, creating a deeper data structure:

my @n = ;
@a.push( @n );  # treats array as a new element
@a.append( @n );  # flattens the array, appends a list
say @a;
# [a b c d e [x y z] x y z]

Re: The ,= operator

[Ralph Mellor]

>  Ralph Mellor  wrote:
> >> > @r = @r , 'd';
> >>
> >> There isn't anything very useful in this behavior though, is there?
>
> Just to be clear, I wasn't saying I didn't think circular references
> should be forbidden, I just specifically meant that you weren't likely
> to want the ",=" operator to create them.

Ah. OK.

My guess is that when they *are* constructed, they're almost always
constructed using `=` and `,`. And that would lead to the same result
and display that use of `,=` does. After all, the latter is just shorthand
for the former.

> But then really, I'm not too likely  ",=" for appending additional array
> elements, I'm more likely to reach for .push.

Indeed. (Or .append.)

My tentative strawman proposal based on discussion thus far is:

* The doc page showing use of `,=` with a hash might benefit from
a parenthetical remark that push/append is the right tool to use with
positionals rather than `,=` because, unlike associatives, for which
flattening is the only sensible semantics, positionals instead default
to *not* flattening (so they more easily retain structure, which is what
most folk want most of the time).

* Liz's "thoughts welcome" is applicable to all things, and in particular
to the gist of self-referential data.

Re: The ,= operator

[Ralph Mellor]

> Zen slicing as a possible way of 'de-containerizing' :
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices

A zen-slice only affects the single reference it's applied to.

And it is a no op when applied to anything other than a `Scalar`.

So it'll have no effect when applied directly to an array, list, hash,
or other non `Scalar`.

Perhaps you're thinking "decontainerizing" does something other
than what it does? It's really a very simple operation. An analogy
is having a bunch of folk, some of whom always go by their legal
name, but others who sometimes go by their nickname. And let's
say there's an operation called "use legal name". When applied
to a nickname it yields the corresponding legal name. But when
applied to a legal name it just yields that name, i.e. it's a no op.

That's all that decont does, except the analog to a nickname is
a `Scalar`, and the analog to a legal name is anything else.

> Even if the ",=" postfix operator were to gain this ability on non-hash
> objects, then hash-objects would be special-cased in **not** requiring
> a Zen-sliced decontainerized object on the LHS, so people would have
> to consider that outcome.

I think the focus on `,=`.is really unfortunate, because the real issue is
just about what `=` does with a non-`Scalar` on its LHS and a list of
values on its RHS. It's really got nothing whatsoever to do with `,`.

It just depends on the type of non-`Scalar` on the LHS of `=`.

Look what happens without not a comma in sight:

my %hash = do for ^1 { %hash }
say %hash; # {}

If it's a hash,, the only sensible thing to do with a list of values that may
each be a pair, or a list of pairs, or an array of pairs, or a hash of pairs,
is to flatten and concatenate all the individual pairs into the hash.

my @array = do for ^1 { @array }
say @array; # (\Array_73652568 = [Array_73652568])

But if it's an array, the sensible thing to do is to *not* flatten by default.

Re: The ,= operator

[William Michels via perl6-users]

On Sun, Nov 29, 2020 at 9:16 AM Joseph Brenner  wrote:
>
> William Michels  wrote:
> >> > "Perhaps more importantly, what improvement do you propose?"
> >
> > Apologies for top-posting, but what immediately comes to my mind upon
> > encountering the creation of a self-referential (circular/infinite)
> > object is proverbially 'going-down-a-level' and trying again. So I
> > tried 1. 'decontainerizing' the object on the LHS, and then 2. using
> > the ",=" postfix to add an additional element (or many). Nothing
> > worked.
>
> I think the trouble with ideas like that is once you accept that
>
>   @a ,= 'd';
>
> Is necessarily a short-form of:
>
>   @a = @a, 'd';
>
> You can see the thing you need to decontainerize is that @a on
> the RHS:
>
>   @a = | @a, 'd';
>
> But you can't get at it in the short form.
>
> (So you wouldn't normally try to use the short form with arrays.)

Hi Joe, what would you expect the code below to produce?

%h<> ,= c => 3;
@a[] ,= 'd';

Best, Bill.

Re: The ,= operator

[Joseph Brenner]

William Michels  wrote:
>> > "Perhaps more importantly, what improvement do you propose?"
>
> Apologies for top-posting, but what immediately comes to my mind upon
> encountering the creation of a self-referential (circular/infinite)
> object is proverbially 'going-down-a-level' and trying again. So I
> tried 1. 'decontainerizing' the object on the LHS, and then 2. using
> the ",=" postfix to add an additional element (or many). Nothing
> worked.

I think the trouble with ideas like that is once you accept that

  @a ,= 'd';

Is necessarily a short-form of:

  @a = @a, 'd';

You can see the thing you need to decontainerize is that @a on
the RHS:

  @a = | @a, 'd';

But you can't get at it in the short form.

(So you wouldn't normally try to use the short form with arrays.)

Re: The ,= operator

[Joseph Brenner]

Joseph Brenner  wrote:

> Just to be clear, I wasn't saying I didn't think circular references
should be forbidden,

Sorry about the double-negative.  It could use another "not" to triple it.

Re: The ,= operator

[Joseph Brenner]

 Ralph Mellor  wrote:
>> > @r = @r , 'd';
>>
>> Okay, that makes sense.  So the circular reference I thought I
>> was seeing is really there, and it's working as designed.
>>
>> There isn't anything very useful in this behavior though, is there?
>
> Yes.
>
> Here are some relevant results from a search for "self referential" in
> the #perl6 and #raku logs.

Just to be clear, I wasn't saying I didn't think circular references
should be forbidden, I just specifically meant that you weren't likely
to want the ",=" operator to create them.

But then really, I'm not too likely  ",=" for appending additional
array elements, I'm more likely to reach for .push.

Re: The ,= operator

[Parrot Raiser]

P.S. My apologies for top-posting in the quoted text, and my apologies
to William for the duplication.

On 11/29/20, Parrot Raiser <1parr...@gmail.com> wrote:
> Having a consistent ("regular", in the linguistic sense), structure
> for something like the op= form is obviously very desirable. It's so
> much easier to teach and learn a rule like "op= has the same effect,
> whatever "op" is; it takes the variable on the LHS, applies the
> operator to its contents and the other value on the RHS, then puts the
> result back on the LHS side. E.g. $x ,= 2 has the same effect as
> $x = $x + 2 than some irregular, complicated set of conditions in
> certain circumstances,  *E.g. the English conjugation of "to be"; "Me
> be confused".
>
> In this case, unless I have misunderstood the examples, the
> complication appears to be in the effect of the operation, regardless
> of its abbreviation by ,=  Perhaps there's a special case that should
> be pointed out as something that needs more grokking than += or ~=,
> and discussed  under ",", which is actually the tricky operation?
>
> On 11/28/20, William Michels via perl6-users  wrote:
>>> > "Perhaps more importantly, what improvement do you propose?"
>>
>> Apologies for top-posting, but what immediately comes to my mind upon
>> encountering the creation of a self-referential (circular/infinite)
>> object is proverbially 'going-down-a-level' and trying again. So I
>> tried 1. 'decontainerizing' the object on the LHS, and then 2. using
>> the ",=" postfix to add an additional element (or many). Nothing
>> worked.
>>
>> Decont:
>> https://docs.raku.org/language/glossary#index-entry-decont
>>
>> Zen slicing as a possible way of 'de-containerizing' :
>> https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>>
>> Even if the ",=" postfix operator were to gain this ability on
>> non-hash objects, then hash-objects would be special-cased in **not**
>> requiring a Zen-sliced decontainerized object on the LHS, so people
>> would have to consider that outcome.
>>
>> Best Regards, Bill.
>>
>>
>>
>> On Sat, Nov 28, 2020 at 8:33 AM Ralph Mellor 
>> wrote:
>>>
>>> > > @r = @r , 'd';
>>> >
>>> > Okay, that makes sense.  So the circular reference I thought I
>>> > was seeing is really there, and it's working as designed.
>>> >
>>> > There isn't anything very useful in this behavior though, is there?
>>>
>>> Yes.
>>>
>>> Here are some relevant results from a search for "self referential" in
>>> the #perl6 and #raku logs.
>>>
>>> 2006
>>> https://colabti.org/irclogger/irclogger_log/perl6?date=2006-01-06#l567
>>> > stevan: dunno about ML (or whatever TaPL uses), but IIRC scheme's
>>> letrec is a form of let which allows things to be self referential
>>>
>>> 2012
>>> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-01-01#l107
>>> my $ff=1;
>>> constant @primes =
>>> 2, 3, 5,
>>> -> $n is copy { repeat { $n += 2 + ($ff=!$ff)*2 } until $n %% none
>>> @primes ... * > sqrt $n; $n; }
>>> ... *;
>>> say @primes[^10]; # OUTPUT«2 3 5 7 11 13 17 19 23 29␤»
>>>
>>> 2012
>>> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-10-05#l582
>>> > TimToady: I'd like to get to the point where we can do hamming numbers
>>> self referentially
>>> constant @hamming = 1, dedup (@hamming X* 2) M (@hamming X* 3) M
>>> (@hamming X* 5);
>>>
>>> 2014
>>> https://colabti.org/irclogger/irclogger_log/perl6?date=2014-11-02#l823
>>> > lizmat: my main reason for not pursuing self referential structures in
>>> > .raku
>>> > lizmat: was that I didn't have a solution for representing them
>>> > lizmat: thoughts on that are very welcome
>>> 
>>> > moritz: lizmat: I fear it must be printed out exactly like that
>>>
>>> 2015
>>> https://colabti.org/irclogger/irclogger_log/perl6?date=2015-08-17#l1558
>>> > vendethiel: TimToady: I read the backlog a bit, but I'm not sure I
>>> > read
>>> > the
>>> answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1
>>> ...) (à la haskell)?
>>> > TimToady: not sure it makes sense with 'my' due to assignment
>>> > semantic,
>>> but would certainly be nice if 'constant' could be self referential

Fwd: The ,= operator

[Parrot Raiser]

Having a consistent ("regular", in the linguistic sense), structure
for something like the op= form is obviously very desirable. It's so
much easier to teach and learn a rule like "op= has the same effect,
whatever "op" is; it takes the variable on the LHS, applies the
operator to its contents and the other value on the RHS, then puts the
result back on the LHS side. E.g. $x ,= 2 has the same effect as
$x = $x + 2 than some irregular, complicated set of conditions in
certain circumstances,  *E.g. the English conjugation of "to be"; "Me
be confused".

In this case, unless I have misunderstood the examples, the
complication appears to be in the effect of the operation, regardless
of its abbreviation by ,=  Perhaps there's a special case that should
be pointed out as something that needs more grokking than += or ~=,
and discussed  under ",", which is actually the tricky operation?

On 11/28/20, William Michels via perl6-users  wrote:
>> > "Perhaps more importantly, what improvement do you propose?"
>
> Apologies for top-posting, but what immediately comes to my mind upon
> encountering the creation of a self-referential (circular/infinite)
> object is proverbially 'going-down-a-level' and trying again. So I
> tried 1. 'decontainerizing' the object on the LHS, and then 2. using
> the ",=" postfix to add an additional element (or many). Nothing
> worked.
>
> Decont:
> https://docs.raku.org/language/glossary#index-entry-decont
>
> Zen slicing as a possible way of 'de-containerizing' :
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices
>
> Even if the ",=" postfix operator were to gain this ability on
> non-hash objects, then hash-objects would be special-cased in **not**
> requiring a Zen-sliced decontainerized object on the LHS, so people
> would have to consider that outcome.
>
> Best Regards, Bill.
>
>
>
> On Sat, Nov 28, 2020 at 8:33 AM Ralph Mellor 
> wrote:
>>
>> > > @r = @r , 'd';
>> >
>> > Okay, that makes sense.  So the circular reference I thought I
>> > was seeing is really there, and it's working as designed.
>> >
>> > There isn't anything very useful in this behavior though, is there?
>>
>> Yes.
>>
>> Here are some relevant results from a search for "self referential" in
>> the #perl6 and #raku logs.
>>
>> 2006
>> https://colabti.org/irclogger/irclogger_log/perl6?date=2006-01-06#l567
>> > stevan: dunno about ML (or whatever TaPL uses), but IIRC scheme's
>> letrec is a form of let which allows things to be self referential
>>
>> 2012
>> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-01-01#l107
>> my $ff=1;
>> constant @primes =
>> 2, 3, 5,
>> -> $n is copy { repeat { $n += 2 + ($ff=!$ff)*2 } until $n %% none
>> @primes ... * > sqrt $n; $n; }
>> ... *;
>> say @primes[^10]; # OUTPUT«2 3 5 7 11 13 17 19 23 29␤»
>>
>> 2012
>> https://colabti.org/irclogger/irclogger_log/perl6?date=2012-10-05#l582
>> > TimToady: I'd like to get to the point where we can do hamming numbers
>> self referentially
>> constant @hamming = 1, dedup (@hamming X* 2) M (@hamming X* 3) M
>> (@hamming X* 5);
>>
>> 2014
>> https://colabti.org/irclogger/irclogger_log/perl6?date=2014-11-02#l823
>> > lizmat: my main reason for not pursuing self referential structures in
>> > .raku
>> > lizmat: was that I didn't have a solution for representing them
>> > lizmat: thoughts on that are very welcome
>> 
>> > moritz: lizmat: I fear it must be printed out exactly like that
>>
>> 2015
>> https://colabti.org/irclogger/irclogger_log/perl6?date=2015-08-17#l1558
>> > vendethiel: TimToady: I read the backlog a bit, but I'm not sure I read
>> > the
>> answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1
>> ...) (à la haskell)?
>> > TimToady: not sure it makes sense with 'my' due to assignment semantic,
>> but would certainly be nice if 'constant' could be self referential
>> > TimToady: and we might intuit a lazy if we see the same symbol on the
>> > left and right
>> > TimToady: haskell obviously never needs to have explicit lazy, since
>> > everything already is...
>> .
>> > Also (the immediate point, really) this isn't described very well
>> > in the documentation.
>>
>> I'd say the first focus is best `.raku`. But perhaps it's already
>> optimal.
>> Then again, I imagine "thoughts on that are very welcome" still applies.
>>
>> It's always appropr

Re: The ,= operator

[William Michels via perl6-users]

> > "Perhaps more importantly, what improvement do you propose?"

Apologies for top-posting, but what immediately comes to my mind upon
encountering the creation of a self-referential (circular/infinite)
object is proverbially 'going-down-a-level' and trying again. So I
tried 1. 'decontainerizing' the object on the LHS, and then 2. using
the ",=" postfix to add an additional element (or many). Nothing
worked.

Decont:
https://docs.raku.org/language/glossary#index-entry-decont

Zen slicing as a possible way of 'de-containerizing' :
https://docs.raku.org/language/subscripts#index-entry-Zen_slices

Even if the ",=" postfix operator were to gain this ability on
non-hash objects, then hash-objects would be special-cased in **not**
requiring a Zen-sliced decontainerized object on the LHS, so people
would have to consider that outcome.

Best Regards, Bill.



On Sat, Nov 28, 2020 at 8:33 AM Ralph Mellor  wrote:
>
> > > @r = @r , 'd';
> >
> > Okay, that makes sense.  So the circular reference I thought I
> > was seeing is really there, and it's working as designed.
> >
> > There isn't anything very useful in this behavior though, is there?
>
> Yes.
>
> Here are some relevant results from a search for "self referential" in
> the #perl6 and #raku logs.
>
> 2006 https://colabti.org/irclogger/irclogger_log/perl6?date=2006-01-06#l567
> > stevan: dunno about ML (or whatever TaPL uses), but IIRC scheme's
> letrec is a form of let which allows things to be self referential
>
> 2012 https://colabti.org/irclogger/irclogger_log/perl6?date=2012-01-01#l107
> my $ff=1;
> constant @primes =
> 2, 3, 5,
> -> $n is copy { repeat { $n += 2 + ($ff=!$ff)*2 } until $n %% none
> @primes ... * > sqrt $n; $n; }
> ... *;
> say @primes[^10]; # OUTPUT«2 3 5 7 11 13 17 19 23 29␤»
>
> 2012 https://colabti.org/irclogger/irclogger_log/perl6?date=2012-10-05#l582
> > TimToady: I'd like to get to the point where we can do hamming numbers
> self referentially
> constant @hamming = 1, dedup (@hamming X* 2) M (@hamming X* 3) M
> (@hamming X* 5);
>
> 2014 https://colabti.org/irclogger/irclogger_log/perl6?date=2014-11-02#l823
> > lizmat: my main reason for not pursuing self referential structures in .raku
> > lizmat: was that I didn't have a solution for representing them
> > lizmat: thoughts on that are very welcome
> 
> > moritz: lizmat: I fear it must be printed out exactly like that
>
> 2015 https://colabti.org/irclogger/irclogger_log/perl6?date=2015-08-17#l1558
> > vendethiel: TimToady: I read the backlog a bit, but I'm not sure I read the
> answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1
> ...) (à la haskell)?
> > TimToady: not sure it makes sense with 'my' due to assignment semantic,
> but would certainly be nice if 'constant' could be self referential
> > TimToady: and we might intuit a lazy if we see the same symbol on the left 
> > and right
> > TimToady: haskell obviously never needs to have explicit lazy, since 
> > everything already is...
> .
> > Also (the immediate point, really) this isn't described very well
> > in the documentation.
>
> I'd say the first focus is best `.raku`. But perhaps it's already optimal.
> Then again, I imagine "thoughts on that are very welcome" still applies.
>
> It's always appropriate to consider improving the doc, especially
> imo if a draft of an improvement is written by, or in cooperation
> with, folk who encountered a problem..
>
> > Just to be thoroughly clear, since with a hash this works ...
> > My first guess was that for arrays, this would work:
> > But here, while @all_at_once is just: [a b c] the array
> > @in_stages has a peculiar structure containing circular references.
>
> Each hash in a list of hashes is automatically flattened:
>
> my %hash = { :a, :b }, { :c, :d }
> say %hash; # {a => True, b => True, c => True, d => True}
>
> Whereas each array in a list of arrays is not:
>
> my @array = [ :a, :b ], [ :c, :d ];
> say @array; # [[a => True b => True] [c => True d => True]]
>
> This is the "class dependent" aspect of the semantics of `=`.
>
> You could create a new array type SteamRolled and bind that:
>
> my @array is SteamRolled = [ :a, :b ], [ :c, :d ];
> say @array; # [a => True b => True, c => True d => True]
>
> Then using the `,=` op would do as you desire.
>
> >say @r; # ( [ d])
>
> "Thoughts are welcome". :)
>
> > And not to quibble too much, but if you didn't want this to do
> > that to the array, then it *is* "mangling" it.
>
> I hear you don't feel sufficientl

Re: The ,= operator

[Ralph Mellor]

> > @r = @r , 'd';
>
> Okay, that makes sense.  So the circular reference I thought I
> was seeing is really there, and it's working as designed.
>
> There isn't anything very useful in this behavior though, is there?

Yes.

Here are some relevant results from a search for "self referential" in
the #perl6 and #raku logs.

2006 https://colabti.org/irclogger/irclogger_log/perl6?date=2006-01-06#l567
> stevan: dunno about ML (or whatever TaPL uses), but IIRC scheme's
letrec is a form of let which allows things to be self referential

2012 https://colabti.org/irclogger/irclogger_log/perl6?date=2012-01-01#l107
my $ff=1;
constant @primes =
2, 3, 5,
-> $n is copy { repeat { $n += 2 + ($ff=!$ff)*2 } until $n %% none
@primes ... * > sqrt $n; $n; }
... *;
say @primes[^10]; # OUTPUT«2 3 5 7 11 13 17 19 23 29␤»

2012 https://colabti.org/irclogger/irclogger_log/perl6?date=2012-10-05#l582
> TimToady: I'd like to get to the point where we can do hamming numbers
self referentially
constant @hamming = 1, dedup (@hamming X* 2) M (@hamming X* 3) M
(@hamming X* 5);

2014 https://colabti.org/irclogger/irclogger_log/perl6?date=2014-11-02#l823
> lizmat: my main reason for not pursuing self referential structures in .raku
> lizmat: was that I didn't have a solution for representing them
> lizmat: thoughts on that are very welcome

> moritz: lizmat: I fear it must be printed out exactly like that

2015 https://colabti.org/irclogger/irclogger_log/perl6?date=2015-08-17#l1558
> vendethiel: TimToady: I read the backlog a bit, but I'm not sure I read the
answer to this question: do you want "my @a = 1, @a" to be (1, 1, 1
...) (à la haskell)?
> TimToady: not sure it makes sense with 'my' due to assignment semantic,
but would certainly be nice if 'constant' could be self referential
> TimToady: and we might intuit a lazy if we see the same symbol on the left 
> and right
> TimToady: haskell obviously never needs to have explicit lazy, since 
> everything already is...
.
> Also (the immediate point, really) this isn't described very well
> in the documentation.

I'd say the first focus is best `.raku`. But perhaps it's already optimal.
Then again, I imagine "thoughts on that are very welcome" still applies.

It's always appropriate to consider improving the doc, especially
imo if a draft of an improvement is written by, or in cooperation
with, folk who encountered a problem..

> Just to be thoroughly clear, since with a hash this works ...
> My first guess was that for arrays, this would work:
> But here, while @all_at_once is just: [a b c] the array
> @in_stages has a peculiar structure containing circular references.

Each hash in a list of hashes is automatically flattened:

my %hash = { :a, :b }, { :c, :d }
say %hash; # {a => True, b => True, c => True, d => True}

Whereas each array in a list of arrays is not:

my @array = [ :a, :b ], [ :c, :d ];
say @array; # [[a => True b => True] [c => True d => True]]

This is the "class dependent" aspect of the semantics of `=`.

You could create a new array type SteamRolled and bind that:

my @array is SteamRolled = [ :a, :b ], [ :c, :d ];
say @array; # [a => True b => True, c => True d => True]

Then using the `,=` op would do as you desire.

>say @r; # ( [ d])

"Thoughts are welcome". :)

> And not to quibble too much, but if you didn't want this to do
> that to the array, then it *is* "mangling" it.

I hear you don't feel sufficiently heard about it being "mangling",
but I just wanted to be clear it was not doing what you may have
thought was going on, namely exhibiting an unintended bug.

 > I think that means you're never going to want to do this.
>  It could be it should even be warning or erroring out.

Per the above IRC discussions, self referential data is useful.

That said, Larry's comment above about perhaps outlawing it
for `my` variables and instead only allowing it for `constant`s is
the way to go.

> > It isn't really anything to do with "class dependent" behaviour.
>
> In which case, the documentation could use some improvement.

I am always supportive of at least discussing improvement of any
aspect of Raku, especially in response to someone experiencing
a surprise or confusion.

My comment above was meant to be about `,=`.

The difference in behaviour between arrays and hashes for what
they do when a list is assigned *is* class dependent behaviour.

> (Actually, saying that some behavior in Raku is class dependent is
> kind of redundant... it's all class dependent in one way or another.)

Right. But I think *something* needs to be said about how the LHS
gets to decide what happens when you use `=` based on the class
of the LHS..

This is different from what happens with, say, `:=`, where the overall
behaviour is essentially the same regardless of the class of the LHS.

> > Perhaps more importantly, what improvement do you propose?
>
> Well, I just mentioned a few.  I always want to see more examples
> in the docs.

Write them, collaborating with those working on the 

Re: The ,= operator

[Joseph Brenner]

About the documentation in general...

> > that particular pair-input syntax is my least favorite.
> > Flipping around the order of key and value when the value is a numeric...?
> >
> > And it isn't needed to demo the operator, any pair input syntax works.
> > I might argue that examples should 
>
> I think the docs reflect a desire to show rich examples that go
> beyond the bare minimum.
>
> For some purposes that's a great thing. For others it's a bad thing.

Yes, precisely.  I can understand wanting to have some flashy
virtuoso raku code out there to show off the language, but I
typically want to see at least a few very basic examples that don't
rely too much on other knowledge (how much is too much is always
a tricky one).

> If you are willing to put a *great deal* of effort into helping evolve the
> doc by both patiently discussing your concerns AND also *writing*
> and/or *rewriting* doc in accord with a mandate to do so based on
> a rough consensus, where rough doesn't mean unfriendly to any of
> those involved, then I am 100% with you, and may even be talked
> into helping a bit.

No, no, when you want to talk someone into doing a lot of work
you tell them how much *fun* it is.

In general I like the material in the docs, but often I think the
features need to be introduced with a few more simple examples
early on (in the spirit of SYNOPSIS sections).

I would think this kind of thing could just be done piecemeal
without being a massive project.

I guess if we were talking about a policy change to say,
always have input data that looks like the .gist output,
that might take some discussion, but even that isn't something
that would have to be rolled out all at once.

> Otherwise, I think that by far the most important thing is that we
> support folk who both really care about improving the doc  ...

Sorry if it sounds like I'm griping a lot.  My tone often comes
off as pretty negative even when I don't intend it.

> > favor the form that "say" is going to spit back to you.
>
> I agree with the sentiment of reducing cognitive load on readers.

Yes, that's exactly it.

Re: The ,= operator

[Joseph Brenner]

First off, much thanks to Ralph Mellor for his detailed explanations.

Ralph Mellor  wrote:

> @r ,= 'd';
>
> The above expands to:
>
> @r = @r , 'd';

Okay, that makes sense.  So the circular reference I thought I
was seeing is really there, and it's working as designed.

There isn't anything very useful in this behavior though, is there?

Also (the immediate point, really) this isn't described very well
in the documentation.

Just to be thoroughly clear, since with a hash this works:

my %all_at_once = a => 1, b => 2, c => 3;

my %in_stages = a => 1;
%in_stages ,= b => 2;
%in_stages ,= c => 3;

(Now %in_stages is the same as %all_at_once.)

My first guess was that for arrays, this would work:

my @all_at_once = 'a', 'b', 'c';

my @in_stages = 'a';
@in_stages ,= 'b';
@in_stages ,= 'c';

But here, while @all_at_once is just: [a b c] the array
@in_stages has a peculiar structure containing circular references.

> >   say @r; # (\Array_53270704 = [Array_53270704 d])
> >   dd @r;  # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"])

> I get both the `gist` (`say`) and `dd` are weird.

> But that's because the value is both infinite and recursively so.

> What else can they to do?

I'm not sure there is much else they could do.  Flagging the
circularity in some way?

   say @r; # ( [ d])

> > So it *does* push a 'd', but it first mangles the original
> > contents of the array.  It looks like @r[0] now has some sort
> > of circular pointer back to @r.

> It's doing exactly what your code told it to do, and the display
> is doing perhaps the most useful thing that can be done, as
> affirmed by the fact you've correctly guessed the right way
> about the circular pointer, but have wrongly guessed that that
> is a resulting of it "mangling"..

Well, actually, I noticed the circular reference by playing with
.keys and explicitly dereferencing with [0] and [1].

And not to quibble too much, but if you didn't want this to do
that to the array, then it *is* "mangling" it.  I get that it's
working as designed, but I think that means you're never going to
want to do this.  It could be it should even be warning or
erroring out.

> > Whatever this "class-dependent" behavior is, I would suggest
> > it's a "fail".  Could this be a bug?

> It isn't really anything to do with "class dependent" behaviour.

In which case, the documentation could use some improvement.
(Actually, saying that some behavior in Raku is class dependent is
kind of redundant... it's all class dependent in one way or another.)

> Perhaps more importantly, what improvement do you propose?

Well, I just mentioned a few.  I always want to see more examples
in the docs.  What else would you use ,= with besides a hash?

Just as an aside:

It could be my confusion here is another form of something else
that keeps tripping me up.   Merging two hashes together is
pretty simple:

  my %h_all = %h1,  %h2;

But doing the same thing with arrays is going to require slipping
the values out of the containers:

  my @a_all = | @a1,  | @a2;

So the two cases aren't all that parallel.

Fwd: The ,= operator

[Ralph Mellor]

I accidentally sent this privately.

-- Forwarded message -
From: Ralph Mellor 
Date: Fri, Nov 27, 2020 at 6:06 PM
Subject: Re: The ,= operator
To: William Michels 

> I can reproduce your results on Rakudo_2020.10, but I'm afraid I don't
> have much more to say about the ",=" operator since I'm unfamiliar
> with it.

It's working as it should.

It *might* be possible to improve the display.



`a ,= b` is just shorthand for `a = a , b`.

This same pattern is used for any `a op= b`.

So `a += b` is the same as `a = a + b`.

So `@r ,= 'd'` is the same as `@r = @r, 'd'`.

Which makes @r a self-referential infinitely recursive data structure.

How does one display it?

I can imagine an argument that it would be better if the *gist*
(as against the `dd`) switched from:

@array_123456789

to

@r

or

@array-that-contains-itself

or

@array-that-contains-itself_1

But I'm not sure if any of those suggestions are *improvements*,
nor whether they are viable / sensible.



> Do the "docs" page(s) make more sense changing the phrase
> "class-dependent" behavior to "hash-dependent" behavior?

The "class dependent" behavior is really a red herring.

See my other other reply to Joe for a detailed discussion.

Re: The ,= operator

[Ralph Mellor]

@r ,= 'd';

The above expands to:

@r = @r , 'd';

That in turn passes a list of two values to the LHS receiver.

That receiver is `@r`, an array, and what arrays do with `=`
is to empty themselves and then assign the list of elements
on the RHS of the `=` into corresponding `Scalar`s stored in
each element of the array.

So you end up with two elements.

**And the first element is a reference to itself**.

>   say @r; # (\Array_53270704 = [Array_53270704 d])
>   dd @r;  # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"])

I get both the `gist` (`say`) and `dd` are weird.

But that's because the value is both infinite and recursively so.

What else can they to do?

One could argue that what they're doing is just about the most
useful thing that could be done.

> So it *does* push a 'd', but it first mangles the original
> contents of the array.  It looks like @r[0] now has some sort
> of circular pointer back to @r.

It's doing exactly what your code told it to do, and the display
is doing perhaps the most useful thing that can be done, as
affirmed by the fact you've correctly guessed the right way
about the circular pointer, but have wrongly guessed that that
is a resulting of it "mangling"..

> Whatever this "class-dependent" behavior is, I would suggest
> it's a "fail".  Could this be a bug?

It isn't really anything to do with "class dependent" behaviour.

Perhaps more importantly, what improvement do you propose?



> I was playing around with this a bit and now I'm wondering what
> it's talking about with that "class-dependent way".

First, to get one suspicion I have out of the way, I suspect it may
actually be object dependent. If so, calling it "class dependent"
may just be intended to be a helpful simplification, and even if it
isn't, I'm going to roll that way and only refer to the dependent
aspect as "class dependent", even if it is in reality potentially
object dependent.



There are two aspects to what happens:

* Syntax -- specifically, use of a `$` sigil on the LHS.

* Class dependence.

Syntax is determined by the compiler, before a class gets to
have any say about what to do. So let's deal with syntax first.

If the LHS receiver of `=` starts with a `$` sigil then "item
assignment" applies.

my $foo   = 1;
$foo  = 2,3; # Useless use of ... 3
say $foo;# 2

Note how the *first* value listed on the right is assigned to
the variable, but any other values are LOUDLY discarded
(i.e. there's a warning message) by the *compiler*:

In all other scenarios, "list assignment" applies. The compiler
passes *all* the RHS values to the LHS receiver, What then
happens depends on the receiver.

It's important to be clear that this first aspect is all about the `$` sigil.

42= 99,100; # "Cannot modify an immutable Int (42)" error

No `$` sigil on the LHS so the above is *list assignment*.

my \foo = $;
foo = 99, 100;
say foo; # (99 100)

Again, the assignment to `foo` is *list assignment*.

Conversely:

my $bar  := 42;
$bar  = 99,100;  # Both "Useless use of ... 100" warning and
"Cannot assign" error

There's a `$` sigil on the LHS so the above is *item assignment*.

$ = 99,100;  # Useless use of constant integer 100

Again, a `$` sigil, so *item assignment* applies.

The `$` sigil has to be at the *start* of what is being considered by
the compiler:

($,$foo)  = 4,5,6;   # 4 thrown away explicitly. 6 thrown away silently.
say $foo;# 5



If the LHS starts with a `$` then, at runtime, it is given a single value.
If it is a `Scalar`, all it does is the metaphoric equivalent of storing that
value "inside" the `Scalar` container. This is what it means to "assign to"
a `Scalar`.



In all other cases the compiler passes *a list of values* at runtime to the
receiver.

What that receiver does with the list depends on the receiver's class.



> that particular pair-input syntax is my least favorite.
> Flipping around the order of key and value when the value is a numeric...?
>
> And it isn't needed to demo the operator, any pair input syntax works.
> I might argue that examples should 

I think the docs reflect a desire to show rich examples that go
beyond the bare minimum.

For some purposes that's a great thing. For others it's a bad thing.

If you are willing to put a *great deal* of effort into helping evolve the
doc by both patiently discussing your concerns AND also *writing*
and/or *rewriting* doc in accord with a mandate to do so based on
a rough consensus, where rough doesn't mean unfriendly to any of
those involved, then I am 100% with you, and may even be talked
into helping a bit.

Otherwise, I think that by far the most important thing is that we
support folk who both really care about improving the doc an

Re: The ,= operator

[William Michels via perl6-users]

Hi Joe,

I can reproduce your results on Rakudo_2020.10, but I'm afraid I don't
have much more to say about the ",=" operator since I'm unfamiliar
with it.

Do the "docs" page(s) make more sense changing the phrase
"class-dependent" behavior to "hash-dependent" behavior?

Best, Bill.


On Thu, Nov 26, 2020 at 2:29 PM Joseph Brenner  wrote:
>
> I was going through the operator list in the documentation the
> other day, and I noticed this one:
>
>   postfix ,=
>
>   Creates an object that concatenates, in a class-dependent way,
>   the contents of the variable on the left hand side and the
>   expression on the right hand side:
>
>  my %a = :11a, :22b;
>  %a ,= :33x;
>  say %a # OUTPUT: «{a => 11, b => 22, x => 33}␤»
>
> I was playing around with this a bit and now I'm wondering what
> it's talking about with that "class-dependent way".
>
> To start with, I've got a small issue with that example:
> that particular pair-input syntax is my least favorite.
> Flipping around the order of key and value when the value is a numeric...?
>
> And it isn't needed to demo the operator, any pair input syntax works.
> I might argue that examples should favor the form that "say" is
> going to spit back to you.  This would be clearer at a glance:
>
>my %b = a => 11, b => 22;
>%b ,= x => 33;
>say %b; # OUTPUT: «{a => 11, b => 22, x => 33}␤»
>
> But where it gets interesting is trying a ,= on something besides
> a hash.  Let's try arrays, where I would expect this to push a
> value onto the array:
>
>   my @r = 'a', 'b', 'c';
>   say @r; # [a b c]
>   @r ,= 'd';
>   say @r; # (\Array_53270704 = [Array_53270704 d])
>   dd @r;  # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"])
>
> It's difficult for me to even see what that is or how I would use it:
>
>   say "keys: ", @r.keys;  # keys: (0 1)
>   say @r[0];  # (\Array_44472736 = [Array_44472736 d])
>   say @r[1];  # d
>
> So it *does* push a 'd', but it first mangles the original
> contents of the array.  It looks like @r[0] now has some sort
> of circular pointer back to @r.
>
> Whatever this "class-dependent" behavior is, I would suggest
> it's a "fail".  Could this be a bug?

The ,= operator

[Joseph Brenner]

I was going through the operator list in the documentation the
other day, and I noticed this one:

  postfix ,=

  Creates an object that concatenates, in a class-dependent way,
  the contents of the variable on the left hand side and the
  expression on the right hand side:

 my %a = :11a, :22b;
 %a ,= :33x;
 say %a # OUTPUT: «{a => 11, b => 22, x => 33}␤»

I was playing around with this a bit and now I'm wondering what
it's talking about with that "class-dependent way".

To start with, I've got a small issue with that example:
that particular pair-input syntax is my least favorite.
Flipping around the order of key and value when the value is a numeric...?

And it isn't needed to demo the operator, any pair input syntax works.
I might argue that examples should favor the form that "say" is
going to spit back to you.  This would be clearer at a glance:

   my %b = a => 11, b => 22;
   %b ,= x => 33;
   say %b; # OUTPUT: «{a => 11, b => 22, x => 33}␤»

But where it gets interesting is trying a ,= on something besides
a hash.  Let's try arrays, where I would expect this to push a
value onto the array:

  my @r = 'a', 'b', 'c';
  say @r; # [a b c]
  @r ,= 'd';
  say @r; # (\Array_53270704 = [Array_53270704 d])
  dd @r;  # Array @r = ((my @Array_37059224) = [@Array_37059224, "d"])

It's difficult for me to even see what that is or how I would use it:

  say "keys: ", @r.keys;  # keys: (0 1)
  say @r[0];  # (\Array_44472736 = [Array_44472736 d])
  say @r[1];  # d

So it *does* push a 'd', but it first mangles the original
contents of the array.  It looks like @r[0] now has some sort
of circular pointer back to @r.

Whatever this "class-dependent" behavior is, I would suggest
it's a "fail".  Could this be a bug?

Re: cross reduce operator magic

[yary]

here's a way to not re-test a,b == b,a

squish(sort flat map {$_..31 X[&({$^a**$^b+$b**$a})] $_},2..31)

I'm not completely happy with it, but it does work and is about 30% faster

squish(sort [X[&({$^a**$^b+$b**$a})]] 2..31,2..31) eqv squish(sort flat map
{$_..31 X[&({$^a**$^b+$b**$a})] $_},2..31)
True

say (grep {$_ < 1e11}, squish(sort flat map {$_..31 X[&({$^a**$^b+$b**$a})]
$_},2..31)) ~ ' took ' ~ (now - BEGIN now)
...took 0.0161237 vs
say (grep {$_ < 1e11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 2..31,2..31))
~ ' took ' ~ (now - BEGIN now)
...took 0.0240974



-y


On Sun, Oct 11, 2020 at 8:32 PM yary  wrote:

> Since this is a golf exercize, reducing number of characters, why use the
> reduction form when infix is shorter?
>
> squish(sort [X[&({$^a**$^b+$b**$a})]] 2..31,2..31) # from original
> squish(sort 2..31 X[&({$^a**$^b+$b**$a})] 2..31) # infix is 2-chars
> shorter
>
> Also I am trying to do a little un-golf speed-optimizing, the Wiki page
> for the sequence notes that requiring a<=b removes trivial duplicates.
> Let's see what I can figure out in the near future...
>
> -y
>
>
> On Sun, Oct 11, 2020 at 5:55 PM Cezmi Pastirma 
> wrote:
>
>> Wow, that's a very comprehensive explanation. I've just found out that I
>> couldn't even comprehend the first reduction operator. I was thinking it
>> was doing some magic operations. All it did was enable the cross op to act
>> on the 2 lists without having to be  between   them. As simple as that. And
>> surely I mis-took the second bracket as a second reduction. Now it's clear
>> that it's for Nesting of metaoperators
>> <https://docs.raku.org/language/operators#___top>  Actually I was
>> guessing this fine detail must have been documented in the Raku docs but I
>> hadn't the faintest idea how to search for it in the huge docs of Raku :)
>>
>> The custom operator definition to separate the Cross from the Op is very
>> welcome too. I haven't written any custom op in Raku so far and it's good
>> to see it in action.
>>
>> Thank you for your time. Very much appreciated.
>>
>>
>> 11.10.2020, 21:31, "Bruce Gray" :
>>
>> NOTE: 30 minutes from now is the start of the Raku Study Group of the San
>> Francisco Perl Mongers.
>> We can offer a "deep dive" into how the Leyland code works, if that would
>> be helpful.
>> Zoom details here:
>> https://mail.pm.org/pipermail/sanfrancisco-pm/2020-October/004726.html
>>
>>
>>  On Oct 11, 2020, at 10:39 AM, Cezmi Pastirma 
>> wrote:
>>
>>  I've got a question about a Leyland-numbers-listing Raku code which I
>> saw at codegolf.stackexchange.com at
>> https://codegolf.stackexchange.com/a/83013/98132
>>
>>  I've slightly rearranged the code to make it print Leyland numbers up to
>> 1 Billion:
>>  .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
>> 2..32,2..32)
>>
>>  The question in short is:
>>
>>  How does the cross reduce work there?
>>
>>
>> The reduction is a red herring to our understanding here.
>> Note that, when you are only [reducing] on two lists, `[any_op_here] @a,
>> @b` is the same as `@a any_op_here @b`.
>> These are equivalent:
>> say [X+] 2..4, 1..5;
>> say 2..4 X+ 1..5;
>> The operator need not be a meta-operator:
>> say [*] 3, 5;
>> say 3 * 5;
>>
>>  Extra info:
>>
>>  That cross reduce section surely does what this half-pseudo code tries
>> to do:
>>  map { $^a ** $^b + $b ** $a }, 2..32,32…2
>>
>>
>> If @c has 20 elements, and @d has 30 elements, then `@c X+ @d` has 600
>> elements.
>> You cannot produce the equivalent with a simple `map`.
>> (You could with a flattened map-within-a-map)
>>
>>
>> Simplifying your "slightly rearranged” code:
>> .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
>> 2..32,2..32)
>>
>> ...to just the part you are curious about, we get:
>> say [X[&({$^a**$^b+$b**$a})]] 2..4,2..4;
>> (8 17 32 17 54 145 32 145 512)
>>
>> We are only [reducing] on two lists, so we can remove the reduction, and
>> just use the Xop:
>> say 2..4 X[&({$^a**$^b+$b**$a})] 2..4;
>> (8 17 32 17 54 145 32 145 512)
>>
>>
>>  The tricky part here is the use of reduce operators two times in a row,
>> once before the cross operator, once before the & operator, which I guess
>> donates a closure. How to interpret this usage of operators?
>>
>>

Re: cross reduce operator magic

[yary]

Since this is a golf exercize, reducing number of characters, why use the
reduction form when infix is shorter?

squish(sort [X[&({$^a**$^b+$b**$a})]] 2..31,2..31) # from original
squish(sort 2..31 X[&({$^a**$^b+$b**$a})] 2..31) # infix is 2-chars shorter

Also I am trying to do a little un-golf speed-optimizing, the Wiki page for
the sequence notes that requiring a<=b removes trivial duplicates. Let's
see what I can figure out in the near future...

-y


On Sun, Oct 11, 2020 at 5:55 PM Cezmi Pastirma 
wrote:

> Wow, that's a very comprehensive explanation. I've just found out that I
> couldn't even comprehend the first reduction operator. I was thinking it
> was doing some magic operations. All it did was enable the cross op to act
> on the 2 lists without having to be  between   them. As simple as that. And
> surely I mis-took the second bracket as a second reduction. Now it's clear
> that it's for Nesting of metaoperators
> <https://docs.raku.org/language/operators#___top>  Actually I was
> guessing this fine detail must have been documented in the Raku docs but I
> hadn't the faintest idea how to search for it in the huge docs of Raku :)
>
> The custom operator definition to separate the Cross from the Op is very
> welcome too. I haven't written any custom op in Raku so far and it's good
> to see it in action.
>
> Thank you for your time. Very much appreciated.
>
>
> 11.10.2020, 21:31, "Bruce Gray" :
>
> NOTE: 30 minutes from now is the start of the Raku Study Group of the San
> Francisco Perl Mongers.
> We can offer a "deep dive" into how the Leyland code works, if that would
> be helpful.
> Zoom details here:
> https://mail.pm.org/pipermail/sanfrancisco-pm/2020-October/004726.html
>
>
>  On Oct 11, 2020, at 10:39 AM, Cezmi Pastirma 
> wrote:
>
>  I've got a question about a Leyland-numbers-listing Raku code which I saw
> at codegolf.stackexchange.com at
> https://codegolf.stackexchange.com/a/83013/98132
>
>  I've slightly rearranged the code to make it print Leyland numbers up to
> 1 Billion:
>  .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
> 2..32,2..32)
>
>  The question in short is:
>
>  How does the cross reduce work there?
>
>
> The reduction is a red herring to our understanding here.
> Note that, when you are only [reducing] on two lists, `[any_op_here] @a,
> @b` is the same as `@a any_op_here @b`.
> These are equivalent:
> say [X+] 2..4, 1..5;
> say 2..4 X+ 1..5;
> The operator need not be a meta-operator:
> say [*] 3, 5;
> say 3 * 5;
>
>  Extra info:
>
>  That cross reduce section surely does what this half-pseudo code tries to
> do:
>  map { $^a ** $^b + $b ** $a }, 2..32,32…2
>
>
> If @c has 20 elements, and @d has 30 elements, then `@c X+ @d` has 600
> elements.
> You cannot produce the equivalent with a simple `map`.
> (You could with a flattened map-within-a-map)
>
>
> Simplifying your "slightly rearranged” code:
> .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
> 2..32,2..32)
>
> ...to just the part you are curious about, we get:
> say [X[&({$^a**$^b+$b**$a})]] 2..4,2..4;
> (8 17 32 17 54 145 32 145 512)
>
> We are only [reducing] on two lists, so we can remove the reduction, and
> just use the Xop:
> say 2..4 X[&({$^a**$^b+$b**$a})] 2..4;
> (8 17 32 17 54 145 32 145 512)
>
>
>  The tricky part here is the use of reduce operators two times in a row,
> once before the cross operator, once before the & operator, which I guess
> donates a closure. How to interpret this usage of operators?
>
>
>
> The square brackets after the X, I think you mis-took as a second
> reduction.
>
> Those brackets are just there to disambiguate the `op` that the `X` is
> crossing on.
> See: https://docs.raku.org/language/operators#Nesting_of_metaoperators
>
> These are equivalent:
> .say for ^2 X+ ^2;
>     .say for ^2 X[+] ^2;
>
>
> We can create our own operator, to further separate the Cross from the Op:
> multi infix:<⨁> ($a, $b) {
>$a ** $b
> + $b ** $a
> };
> say 2 ⨁ 3;
> say 2..4 X⨁ 2..4;
> 17
> (8 17 32 17 54 145 32 145 512)
>
> The `X` itself is the operator-form of the `cross` routine,
> well-documented here:
> https://docs.raku.org/routine/cross
>
> https://docs.raku.org/language/operators#index-entry-X_(cross_metaoperator)
>
> https://docs.raku.org/language/operators#index-entry-cross_product_operator
>
> If any part of this was lacking in clarity, please let me know where to
> focus, and I will be glad to expound.
>
> --
> Hope this helps,
> Bruce Gray (Util of Perlmonks)
>
>

Re: cross reduce operator magic

[Cezmi Pastirma]

Wow, that's a very comprehensive explanation. I've just found out that I couldn't even comprehend the first reduction operator. I was thinking it was doing some magic operations. All it did was enable the cross op to act on the 2 lists without having to be  between   them. As simple as that. And surely I mis-took the second bracket as a second reduction. Now it's clear that it's for Nesting of metaoperators  Actually I was guessing this fine detail must have been documented in the Raku docs but I hadn't the faintest idea how to search for it in the huge docs of Raku :) The custom operator definition to separate the Cross from the Op is very welcome too. I haven't written any custom op in Raku so far and it's good to see it in action. Thank you for your time. Very much appreciated.11.10.2020, 21:31, "Bruce Gray" :NOTE: 30 minutes from now is the start of the Raku Study Group of the San Francisco Perl Mongers.We can offer a "deep dive" into how the Leyland code works, if that would be helpful.Zoom details here: https://mail.pm.org/pipermail/sanfrancisco-pm/2020-October/004726.html On Oct 11, 2020, at 10:39 AM, Cezmi Pastirma <cezmisi...@yandex.com> wrote:  I've got a question about a Leyland-numbers-listing Raku code which I saw at codegolf.stackexchange.com at https://codegolf.stackexchange.com/a/83013/98132   I've slightly rearranged the code to make it print Leyland numbers up to 1 Billion: .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 2..32,2..32)   The question in short is:   How does the cross reduce work there?The reduction is a red herring to our understanding here.Note that, when you are only [reducing] on two lists, `[any_op_here] @a, @b` is the same as `@a any_op_here @b`.These are equivalent:say [X+] 2..4,  1..5;say 2..4 X+ 1..5;The operator need not be a meta-operator:say [*] 3,  5;say 3 * 5; Extra info:   That cross reduce section surely does what this half-pseudo code tries to do: map { $^a ** $^b + $b ** $a }, 2..32,32…2If @c has 20 elements, and @d has 30 elements, then `@c X+ @d` has 600 elements.You cannot produce the equivalent with a simple `map`.(You could with a flattened map-within-a-map)Simplifying your "slightly rearranged” code:.say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 2..32,2..32)...to just the part you are curious about, we get:say [X[&({$^a**$^b+$b**$a})]] 2..4,2..4;(8 17 32 17 54 145 32 145 512)We are only [reducing] on two lists, so we can remove the reduction, and just use the Xop:say 2..4 X[&({$^a**$^b+$b**$a})] 2..4;(8 17 32 17 54 145 32 145 512) The tricky part here is the use of reduce operators two times in a row, once before the cross operator, once before the & operator, which I guess donates a closure. How to interpret this usage of operators?  The square brackets after the X, I think you mis-took as a second reduction.Those brackets are just there to disambiguate the `op` that the `X` is crossing on.See: https://docs.raku.org/language/operators#Nesting_of_metaoperatorsThese are equivalent:.say for ^2 X+   ^2;.say for ^2 X[+] ^2;We can create our own operator, to further separate the Cross from the Op:multi infix:<⨁> ($a, $b) {   $a ** $b + $b ** $a};say 2 ⨁ 3;say 2..4 X⨁ 2..4;17    (8 17 32 17 54 145 32 145 512)The `X` itself is the operator-form of the `cross` routine, well-documented here:https://docs.raku.org/routine/crosshttps://docs.raku.org/language/operators#index-entry-X_(cross_metaoperator)https://docs.raku.org/language/operators#index-entry-cross_product_operatorIf any part of this was lacking in clarity, please let me know where to focus, and I will be glad to expound.-- Hope this helps,Bruce Gray (Util of Perlmonks)

Re: cross reduce operator magic

[Joseph Brenner]

 Bruce Gray  wrote:
> NOTE: 30 minutes from now is the start of the Raku Study Group of the San
> Francisco Perl Mongers.

Thanks-- though now it's 3 minutes-- but that was the info for last week.
The current one is:

  https://www.meetup.com/San-Francisco-Perl/events/273839687/

In general, you can start at the San Francisco Perl group to get the
latest meeting info:

  https://www.meetup.com/San-Francisco-Perl

> We can offer a "deep dive" into how the Leyland code works, if that would be
> helpful.

I'm glad *you're* offering, I was just looking at that one going uh,
Leyland Numbers?  I haven't even heard of "squish"...




> Zoom details here:
> https://mail.pm.org/pipermail/sanfrancisco-pm/2020-October/004726.html
>
>
>> On Oct 11, 2020, at 10:39 AM, Cezmi Pastirma 
>> wrote:
>>
>> I've got a question about a Leyland-numbers-listing Raku code which I saw
>> at codegolf.stackexchange.com at
>> https://codegolf.stackexchange.com/a/83013/98132
>>
>> I've slightly rearranged the code to make it print Leyland numbers up to 1
>> Billion:
>> .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
>> 2..32,2..32)
>>
>> The question in short is:
>>
>> How does the cross reduce work there?
>
> The reduction is a red herring to our understanding here.
> Note that, when you are only [reducing] on two lists, `[any_op_here] @a, @b`
> is the same as `@a any_op_here @b`.
> These are equivalent:
>   say [X+] 2..4,  1..5;
>   say 2..4 X+ 1..5;
> The operator need not be a meta-operator:
>   say [*] 3,  5;
>   say 3 * 5;
>
>> Extra info:
>>
>> That cross reduce section surely does what this half-pseudo code tries to
>> do:
>> map { $^a ** $^b + $b ** $a }, 2..32,32…2
>
> If @c has 20 elements, and @d has 30 elements, then `@c X+ @d` has 600
> elements.
> You cannot produce the equivalent with a simple `map`.
> (You could with a flattened map-within-a-map)
>
>
> Simplifying your "slightly rearranged” code:
>   .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]]
> 2..32,2..32)
>
> ...to just the part you are curious about, we get:
>   say [X[&({$^a**$^b+$b**$a})]] 2..4,2..4;
>   (8 17 32 17 54 145 32 145 512)
>
> We are only [reducing] on two lists, so we can remove the reduction, and
> just use the Xop:
>   say 2..4 X[&({$^a**$^b+$b**$a})] 2..4;
>   (8 17 32 17 54 145 32 145 512)
>
>
>> The tricky part here is the use of reduce operators two times in a row,
>> once before the cross operator, once before the & operator, which I guess
>> donates a closure. How to interpret this usage of operators?
>>
>
> The square brackets after the X, I think you mis-took as a second
> reduction.
>
> Those brackets are just there to disambiguate the `op` that the `X` is
> crossing on.
> See: https://docs.raku.org/language/operators#Nesting_of_metaoperators
>
> These are equivalent:
> .say for ^2 X+   ^2;
> .say for ^2 X[+] ^2;
>
>
> We can create our own operator, to further separate the Cross from the Op:
>   multi infix:<⨁> ($a, $b) {
>  $a ** $b
>   + $b ** $a
>   };
>   say 2 ⨁ 3;
>   say 2..4 X⨁ 2..4;
>   17
>   (8 17 32 17 54 145 32 145 512)
>
> The `X` itself is the operator-form of the `cross` routine, well-documented
> here:
>   https://docs.raku.org/routine/cross
>   
> https://docs.raku.org/language/operators#index-entry-X_(cross_metaoperator)
>   
> https://docs.raku.org/language/operators#index-entry-cross_product_operator
>
> If any part of this was lacking in clarity, please let me know where to
> focus, and I will be glad to expound.
>
> --
> Hope this helps,
> Bruce Gray (Util of Perlmonks)
>

Re: cross reduce operator magic

[Bruce Gray]

NOTE: 30 minutes from now is the start of the Raku Study Group of the San 
Francisco Perl Mongers.
We can offer a "deep dive" into how the Leyland code works, if that would be 
helpful.
Zoom details here: 
https://mail.pm.org/pipermail/sanfrancisco-pm/2020-October/004726.html


> On Oct 11, 2020, at 10:39 AM, Cezmi Pastirma  wrote:
> 
> I've got a question about a Leyland-numbers-listing Raku code which I saw at 
> codegolf.stackexchange.com at https://codegolf.stackexchange.com/a/83013/98132
>  
> I've slightly rearranged the code to make it print Leyland numbers up to 1 
> Billion:
> .say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 2..32,2..32)
>  
> The question in short is:
>  
> How does the cross reduce work there?

The reduction is a red herring to our understanding here.
Note that, when you are only [reducing] on two lists, `[any_op_here] @a, @b` is 
the same as `@a any_op_here @b`.
These are equivalent:
say [X+] 2..4,  1..5;
say     2..4 X+ 1..5;
The operator need not be a meta-operator:
say [*] 3,  5;
say 3 * 5;

> Extra info:
>  
> That cross reduce section surely does what this half-pseudo code tries to do:
> map { $^a ** $^b + $b ** $a }, 2..32,32…2

If @c has 20 elements, and @d has 30 elements, then `@c X+ @d` has 600 elements.
You cannot produce the equivalent with a simple `map`.
(You could with a flattened map-within-a-map)


Simplifying your "slightly rearranged” code:
.say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 
2..32,2..32)

...to just the part you are curious about, we get:
say [X[&({$^a**$^b+$b**$a})]] 2..4,2..4;
(8 17 32 17 54 145 32 145 512)

We are only [reducing] on two lists, so we can remove the reduction, and just 
use the Xop:
say 2..4 X[&({$^a**$^b+$b**$a})] 2..4;
(8 17 32 17 54 145 32 145 512)


> The tricky part here is the use of reduce operators two times in a row, once 
> before the cross operator, once before the & operator, which I guess donates 
> a closure. How to interpret this usage of operators?
>  

The square brackets after the X, I think you mis-took as a second reduction.

Those brackets are just there to disambiguate the `op` that the `X` is crossing 
on.
See: https://docs.raku.org/language/operators#Nesting_of_metaoperators

These are equivalent:
.say for ^2 X+   ^2;
.say for ^2 X[+] ^2;


We can create our own operator, to further separate the Cross from the Op:
multi infix:<⨁> ($a, $b) {
   $a ** $b 
+ $b ** $a
};
say 2 ⨁ 3;
say 2..4 X⨁ 2..4;
17
(8 17 32 17 54 145 32 145 512)

The `X` itself is the operator-form of the `cross` routine, well-documented 
here:
https://docs.raku.org/routine/cross

https://docs.raku.org/language/operators#index-entry-X_(cross_metaoperator)

https://docs.raku.org/language/operators#index-entry-cross_product_operator

If any part of this was lacking in clarity, please let me know where to focus, 
and I will be glad to expound.

-- 
Hope this helps,
Bruce Gray (Util of Perlmonks)

cross reduce operator magic

[Cezmi Pastirma]

I've got a question about a Leyland-numbers-listing Raku code which I saw at codegolf.stackexchange.com at https://codegolf.stackexchange.com/a/83013/98132 I've slightly rearranged the code to make it print Leyland numbers up to 1 Billion:.say for grep {$_ < 1E11}, squish(sort [X[&({$^a**$^b+$b**$a})]] 2..32,2..32) The question in short is: How does the cross reduce work there? Extra info: That cross reduce section surely does what this half-pseudo code tries to do:map { $^a ** $^b + $b ** $a }, 2..32,32...2The tricky part here is the use of reduce operators two times in a row, once before the cross operator, once before the & operator, which I guess donates a closure. How to interpret this usage of operators? 

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[yary]

I opened a Raku ticket https://github.com/rakudo/rakudo/issues/3839
-y


On Sun, Aug 2, 2020 at 5:42 PM Eirik Berg Hanssen <
eirik-berg.hans...@allverden.no> wrote:

> On Sun, Aug 2, 2020 at 11:14 PM yary  wrote:
>
>> Issue golf, ff is always evaluating its RHS
>>
>> $ raku -e 'say "With ff: ";say ( 1..5 ).grep({False ff .say}); say "With
>> fff: ";say ( 1..5 ).grep({False fff .say});'
>> With ff:
>> 1
>> 2
>> 3
>> 4
>> 5
>> ()
>> With fff:
>> ()
>>
>
>   I haven't looked much at Raku since it was Perl6, but for comparison,
> here's some Perl 5:
>
> $ perl -E 'say "With ..: ";say grep {/nope/ .. say} 1..5; say "With ...:
> ";say grep {/nope/ ... say} 1..5;'
> With ..:
>
> With ...:
>
>
> Eirik
>

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[Eirik Berg Hanssen]

On Sun, Aug 2, 2020 at 11:14 PM yary  wrote:

> Issue golf, ff is always evaluating its RHS
>
> $ raku -e 'say "With ff: ";say ( 1..5 ).grep({False ff .say}); say "With
> fff: ";say ( 1..5 ).grep({False fff .say});'
> With ff:
> 1
> 2
> 3
> 4
> 5
> ()
> With fff:
> ()
>

  I haven't looked much at Raku since it was Perl6, but for comparison,
here's some Perl 5:

$ perl -E 'say "With ..: ";say grep {/nope/ .. say} 1..5; say "With ...:
";say grep {/nope/ ... say} 1..5;'
With ..:

With ...:


Eirik

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[yary]

Issue golf, ff is always evaluating its RHS

$ raku -e 'say "With ff: ";say ( 1..5 ).grep({False ff .say}); say "With
fff: ";say ( 1..5 ).grep({False fff .say});'
With ff:
1
2
3
4
5
()
With fff:
()


-y


On Sun, Aug 2, 2020 at 2:16 PM yary  wrote:

> tl;dr: is this a Rakudo issue?
>
> ooh a puzzle  why do 'ff' and 'fff' give different results in this case?
> The start & end are disjoint, the $++ should only run when the string test
> is true, so I expect 'ff' and 'fff' to behave the same also.
>
> Golfing a little
>
> $ raku -e 'my @input=qw G - 4 5 - hide>; \
> say "With ff:  ",@input.grep({($_ eq "+" && $++ < 2) ff  ($_ eq "-" && $++
> < 2)}); \
> say "With fff: ",@input.grep({($_ eq "+" && $++ < 2) fff ($_ eq "-" && $++
> < 2)});'
>
> With ff:  (+ B C D - + E F - 2 3 - never never + G - 4 5 - hide)
> With fff: (+ B C D - + E F -)
>
> With both of these, the flip-flop turns on with the first '+' and turns
> off with the first '-'
> With both of these, the 2nd '+' turns on the flip-flop.
> WIth 'ff', the flip-flop never turns off, with 'fff' the flip-flop turns
> off when it encounters the next '-'
>
> I wonder... let's have the end of the flip-flop say every time it runs
>
> raku -e 'my @input=qw G - %% && - hide>; \
> say "With ff: ";say @input.grep({($_ eq "+" && $++ < 2) ff  ("checking
> $_".say && $_ eq "-" && say "increment to " ~ ++$ )}); \
> say "With fff:";say @input.grep({($_ eq "+" && $++ < 2) fff ("checking
> $_".say && $_ eq "-" && say "increment to " ~ ++$ )});'
>
> With ff:
> checking nope
> checking +
> checking B
> checking C
> checking D
> checking -
> increment to 1
> checking ??
> checking -
> increment to 2
> checking no
> checking +
> checking E
> checking F
> checking -
> increment to 3
> checking !!
> checking ##
> checking -
> increment to 4
> checking never
> checking never
> checking +
> checking G
> checking -
> increment to 5
> checking %%
> checking &&
> checking -
> increment to 6
> checking hide
> (+ B C D - + E F -)
> With fff:
> checking B
> checking C
> checking D
> checking -
> increment to 1
> checking E
> checking F
> checking -
> increment to 2
> (+ B C D - + E F -)
>
> Hey gurus, why is the end check in 'ff' running so much more often than
> the end check of 'fff' ?
>
> ps. I had many weird errors, due to having "rake" installed, and having
> something autocorrect my "raku" command-line to "rake"!!!
>
> -y
>
>
> On Sat, Aug 1, 2020 at 10:06 PM William Michels 
> wrote:
>
>> Hi Yary, Nice code!
>>
>> The general approach of using an anonymous counter is useful to me. Below
>> are  examples when I only want to recover the first one or two blocks of
>> text starting with "Start" and ending with "Mark" (nota bene: I took your
>> example text and deleted the blank lines):
>>
>> user@book:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) fff ($_ eq
>> "Mark" && $++ < 1);' yary_ff_example2.txt
>> Start
>> hi print me
>> yes!
>> Mark
>> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) ff ($_ eq
>> "Mark" && $++ < 1);' yary_ff_example2.txt
>> Start
>> hi print me
>> yes!
>> Mark
>> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) fff ($_ eq
>> "Mark" && $++ < 2);' yary_ff_example2.txt
>> Start
>> hi print me
>> yes!
>> Mark
>> Start
>> We're back!
>> Mark
>> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) ff ($_ eq
>> "Mark" && $++ < 2);' yary_ff_example2.txt
>> Start
>> hi print me
>> yes!
>> Mark
>> Start
>> We're back!
>> Mark
>> Still here!
>> Start
>> haha that Start does nothing
>> going to end it now
>> Mark
>> !bye bye don't see me!
>> user@mbook:~$
>>
>> I guess I have to say--I'm still a little surprised by the last result
>> using the "ff" infix operator. I'd appreciate knowing why "ff" and "fff"
>> behave differently in the last two examples, since the beginning marker
>> doesn't look anything like the end marker (suggesting t

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[yary]

tl;dr: is this a Rakudo issue?

ooh a puzzle  why do 'ff' and 'fff' give different results in this case?
The start & end are disjoint, the $++ should only run when the string test
is true, so I expect 'ff' and 'fff' to behave the same also.

Golfing a little

$ raku -e 'my @input=qw; \
say "With ff:  ",@input.grep({($_ eq "+" && $++ < 2) ff  ($_ eq "-" && $++
< 2)}); \
say "With fff: ",@input.grep({($_ eq "+" && $++ < 2) fff ($_ eq "-" && $++
< 2)});'

With ff:  (+ B C D - + E F - 2 3 - never never + G - 4 5 - hide)
With fff: (+ B C D - + E F -)

With both of these, the flip-flop turns on with the first '+' and turns off
with the first '-'
With both of these, the 2nd '+' turns on the flip-flop.
WIth 'ff', the flip-flop never turns off, with 'fff' the flip-flop turns
off when it encounters the next '-'

I wonder... let's have the end of the flip-flop say every time it runs

raku -e 'my @input=qw; \
say "With ff: ";say @input.grep({($_ eq "+" && $++ < 2) ff  ("checking
$_".say && $_ eq "-" && say "increment to " ~ ++$ )}); \
say "With fff:";say @input.grep({($_ eq "+" && $++ < 2) fff ("checking
$_".say && $_ eq "-" && say "increment to " ~ ++$ )});'

With ff:
checking nope
checking +
checking B
checking C
checking D
checking -
increment to 1
checking ??
checking -
increment to 2
checking no
checking +
checking E
checking F
checking -
increment to 3
checking !!
checking ##
checking -
increment to 4
checking never
checking never
checking +
checking G
checking -
increment to 5
checking %%
checking &&
checking -
increment to 6
checking hide
(+ B C D - + E F -)
With fff:
checking B
checking C
checking D
checking -
increment to 1
checking E
checking F
checking -
increment to 2
(+ B C D - + E F -)

Hey gurus, why is the end check in 'ff' running so much more often than the
end check of 'fff' ?

ps. I had many weird errors, due to having "rake" installed, and having
something autocorrect my "raku" command-line to "rake"!!!

-y


On Sat, Aug 1, 2020 at 10:06 PM William Michels 
wrote:

> Hi Yary, Nice code!
>
> The general approach of using an anonymous counter is useful to me. Below
> are  examples when I only want to recover the first one or two blocks of
> text starting with "Start" and ending with "Mark" (nota bene: I took your
> example text and deleted the blank lines):
>
> user@book:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) fff ($_ eq
> "Mark" && $++ < 1);' yary_ff_example2.txt
> Start
> hi print me
> yes!
> Mark
> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) ff ($_ eq
> "Mark" && $++ < 1);' yary_ff_example2.txt
> Start
> hi print me
> yes!
> Mark
> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) fff ($_ eq
> "Mark" && $++ < 2);' yary_ff_example2.txt
> Start
> hi print me
> yes!
> Mark
> Start
> We're back!
> Mark
> user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) ff ($_ eq
> "Mark" && $++ < 2);' yary_ff_example2.txt
> Start
> hi print me
> yes!
> Mark
> Start
> We're back!
> Mark
> Still here!
> Start
> haha that Start does nothing
> going to end it now
> Mark
> !bye bye don't see me!
> user@mbook:~$
>
> I guess I have to say--I'm still a little surprised by the last result
> using the "ff" infix operator. I'd appreciate knowing why "ff" and "fff"
> behave differently in the last two examples, since the beginning marker
> doesn't look anything like the end marker (suggesting they should act
> identically). Also, is there a simpler way to write the conditional?
>
> Thx, Bill.
>
>
>
> On Sat, Aug 1, 2020 at 4:04 PM yary  wrote:
> >
> > This made me want to try a contrived puzzle, use 'fff' to show things
> between a "start" and 2nd "mark" line. That is, print any line below not
> marked with "!" at the start
> >
> > $ cat example.txt
> >
> > !ignore me
> >
> > Start
> >
> > hi print me
> >
> > yes!
> >
> > Mark
> >
> > still print me
> >
> > Mark
> >
> > !ignore this line
> >
> > !this line too
> >
> > Start
> >
> > We're back!
> >
> > Mark
> >
> > Still here!
> >
> > Start
> >
> > haha that Start does nothing
> >
> > going t

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[William Michels via perl6-users]

Hi Yary, Nice code!

The general approach of using an anonymous counter is useful to me. Below
are  examples when I only want to recover the first one or two blocks of
text starting with "Start" and ending with "Mark" (nota bene: I took your
example text and deleted the blank lines):

user@book:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) fff ($_ eq
"Mark" && $++ < 1);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 1) ff ($_ eq
"Mark" && $++ < 1);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) fff ($_ eq
"Mark" && $++ < 2);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
Start
We're back!
Mark
user@mbook:~$ raku -ne ' say $_ if ($_ eq "Start" && $++ < 2) ff ($_ eq
"Mark" && $++ < 2);' yary_ff_example2.txt
Start
hi print me
yes!
Mark
Start
We're back!
Mark
Still here!
Start
haha that Start does nothing
going to end it now
Mark
!bye bye don't see me!
user@mbook:~$

I guess I have to say--I'm still a little surprised by the last result
using the "ff" infix operator. I'd appreciate knowing why "ff" and "fff"
behave differently in the last two examples, since the beginning marker
doesn't look anything like the end marker (suggesting they should act
identically). Also, is there a simpler way to write the conditional?

Thx, Bill.



On Sat, Aug 1, 2020 at 4:04 PM yary  wrote:
>
> This made me want to try a contrived puzzle, use 'fff' to show things
between a "start" and 2nd "mark" line. That is, print any line below not
marked with "!" at the start
>
> $ cat example.txt
>
> !ignore me
>
> Start
>
> hi print me
>
> yes!
>
> Mark
>
> still print me
>
> Mark
>
> !ignore this line
>
> !this line too
>
> Start
>
> We're back!
>
> Mark
>
> Still here!
>
> Start
>
> haha that Start does nothing
>
> going to end it now
>
> Mark
>
> !bye bye don't see me!
>
>
> Let's see...ooh that was easy!!
>
> raku -ne '.say if "Start" ff ($_ eq "Mark" && ++$ %% 2)' example.txt
>
>
> That increments the anonymous state variable $ and then checks if it is
divisible by 2, so that only every 2nd Mark returns True
>
> Don't know if I'll ever need it, fun to have it.
>
> -y
>
>
> On Tue, Jul 28, 2020 at 7:09 PM Brad Gilbert  wrote:
>>
>> A regex doesn't have to match the entire string.
>>
>> 'abcd' ~~ / bc /
>> # ｢bc｣
>>
>> A string has to match exactly with the smart-match. (`ff` and `fff` do
smart-match)
>>
>> 'abcd' ~~ 'bc' # False
>> 'abcd' ~~ 'abcd' # True
>>
>> A string inside of a regex only makes that a single atom, it does not
make it match like just a string.
>>
>> 'abcd' ~~ / 'bc' /
>> # ｢bc｣
>>
>>  'aBaBaB' ~~ / aB+ /
>> ｢aB｣
>>
>>  'aBaBaB' ~~ / "aB"+ /
>> ｢aBaBaB｣
>>
>> In fact a string inside of a regex doesn't do much more than square
brackets.
>>
>>  'aBaBaB' ~~ / [aB]+ /
>> ｢aBaBaB｣
>>
>> If you want the regex to match fully, add a beginning of string and end
of string marker.
>>
>> 'abcd' ~~ / ^ bc $ /
>> # Nil
>>
>> 'abcd' ~~ / ^ abcd $ /
>> # ｢abcd｣
>>
>> ---
>>
>> Since `ff` can begin and end at the same time, the following is turning
on and off at almost every iteration of the loop after it starts.
>>
>> $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/
;' startling.txt
>> on star
>> on off start
>> on off startl
>> on off startli
>> on off startlin
>> on off startling
>>
>> On Tue, Jul 28, 2020 at 1:43 PM William Michels 
wrote:
>>>
>>> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
>>> operators in Raku to me!
>>>
>>> I have to admit that I'm still fuzzy on the particulars between "ff"
>>> and "fff", since I am not familiar with the sed function. I can
>>> certainly understand how useful these functions could be to 'pull out
>>> all PGP signatures' from a file (which was the Perl5 example given in
>>> the Oracle Linux Blog). So I can now  pull out the html "head" section
>>> from the page _ https://raku.org/fun/ _ (saved locally as file
>>> "fun.txt") using the f

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[yary]

This made me want to try a contrived puzzle, use 'fff' to show things
between a "start" and 2nd "mark" line. That is, print any line below not
marked with "!" at the start

$ cat example.txt

!ignore me

Start

hi print me

yes!

Mark

still print me

Mark

!ignore this line

!this line too

Start

We're back!

Mark

Still here!

Start

haha that Start does nothing

going to end it now

Mark

!bye bye don't see me!

Let's see...ooh that was easy!!

raku -ne '.say if "Start" ff ($_ eq "Mark" && ++$ %% 2)' example.txt

That increments the anonymous state variable $ and then checks if it is
divisible by 2, so that only every 2nd Mark returns True

Don't know if I'll ever need it, fun to have it.

-y


On Tue, Jul 28, 2020 at 7:09 PM Brad Gilbert  wrote:

> A regex doesn't have to match the entire string.
>
> 'abcd' ~~ / bc /
> # ｢bc｣
>
> A string has to match exactly with the smart-match. (`ff` and `fff` do
> smart-match)
>
> 'abcd' ~~ 'bc' # False
> 'abcd' ~~ 'abcd' # True
>
> A string inside of a regex only makes that a single atom, it does not make
> it match like just a string.
>
> 'abcd' ~~ / 'bc' /
> # ｢bc｣
>
>  'aBaBaB' ~~ / aB+ /
> ｢aB｣
>
>  'aBaBaB' ~~ / "aB"+ /
> ｢aBaBaB｣
>
> In fact a string inside of a regex doesn't do much more than square
> brackets.
>
>  'aBaBaB' ~~ / [aB]+ /
> ｢aBaBaB｣
>
> If you want the regex to match fully, add a beginning of string and end of
> string marker.
>
> 'abcd' ~~ / ^ bc $ /
> # Nil
>
> 'abcd' ~~ / ^ abcd $ /
> # ｢abcd｣
>
> ---
>
> Since `ff` can begin and end at the same time, the following is turning on
> and off at almost every iteration of the loop after it starts.
>
> $ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/
> ;' startling.txt
> on star
> on off start
> on off startl
> on off startli
> on off startlin
> on off startling
>
> On Tue, Jul 28, 2020 at 1:43 PM William Michels 
> wrote:
>
>> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
>> operators in Raku to me!
>>
>> I have to admit that I'm still fuzzy on the particulars between "ff"
>> and "fff", since I am not familiar with the sed function. I can
>> certainly understand how useful these functions could be to 'pull out
>> all PGP signatures' from a file (which was the Perl5 example given in
>> the Oracle Linux Blog). So I can now  pull out the html "head" section
>> from the page _ https://raku.org/fun/ _ (saved locally as file
>> "fun.txt") using the following Raku code:
>>
>> user@mbook:~$ raku -ne '.put if Q[] ff Q[]' fun.txt
>> 
>> 
>> 
>> 
>> Raku is optimized for fun!
>>
>>
>> 
>> 
>> 
>> 
>>
>> 
>> user@mbook:~$
>>
>> What I'm less clear on is how the code below is functioning. I first
>> print out file named "startling.txt" with 'cat':  it's supposed to
>> stand in for a text delimited linewise by "header 1", "header 2", etc.
>> After the 'cat' example, I show three examples with Perl(v5.26.3) and
>> three examples with Raku(2020.06), generally comparing literal vs
>> regex arguments.
>>
>> The first two Perl5 examples returns nothing; the third Perl5 example
>> returns everything after the "star" line. For the Raku code, the
>> 'DWIMmiest' output below is the first Raku example, which returns two
>> lines, "star" and "start". This is what I expected/desired. But I'm
>> not really understanding what's happening with the other 2 Raku
>> examples (which return everything after the "star" line):
>>
>> user@mbook:~$ cat startling.txt
>> s
>> st
>> sta
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>>
>> user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt
>> user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt
>> user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt
>> star
>> start
>> user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt
>> star
>> start
>> startl
>> startli
>> startlin
>> startling
>> user@mbook:~$
>>
>> I'm all in favor of improving the "ff" and "fff" functions in Raku
>> over their Perl5 counterparts, but I'm hoping to gain a better
>> (mnemonic?) way of remembering the expected return values with literal
>> vs regex arguments.
>>
>> Any assistance appreciated, Bill.
>>
>>
>>
>>
>>
>>
>> On Sun, Jul 26, 2020 at 10:04 AM Larry Wall  wrote:
>> >
>> > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
>> > : In the above two cases ff and fff would behave identically.
>> > :
>> > : The difference shines when the beginning marker can look like the end
>> > : marker.
>> >
>> > The way I think of it is this:  You come to the end of "ff" sooner, so
>> you
>> > do the end 

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[Brad Gilbert]

A regex doesn't have to match the entire string.

'abcd' ~~ / bc /
# ｢bc｣

A string has to match exactly with the smart-match. (`ff` and `fff` do
smart-match)

'abcd' ~~ 'bc' # False
'abcd' ~~ 'abcd' # True

A string inside of a regex only makes that a single atom, it does not make
it match like just a string.

'abcd' ~~ / 'bc' /
# ｢bc｣

 'aBaBaB' ~~ / aB+ /
｢aB｣

 'aBaBaB' ~~ / "aB"+ /
｢aBaBaB｣

In fact a string inside of a regex doesn't do much more than square
brackets.

 'aBaBaB' ~~ / [aB]+ /
｢aBaBaB｣

If you want the regex to match fully, add a beginning of string and end of
string marker.

'abcd' ~~ / ^ bc $ /
# Nil

'abcd' ~~ / ^ abcd $ /
# ｢abcd｣

---

Since `ff` can begin and end at the same time, the following is turning on
and off at almost every iteration of the loop after it starts.

$ raku -ne '.put if /star {print q[on ]}/ ff /start {print q[off ]}/ ;'
startling.txt
on star
on off start
on off startl
on off startli
on off startlin
on off startling

On Tue, Jul 28, 2020 at 1:43 PM William Michels 
wrote:

> Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
> operators in Raku to me!
>
> I have to admit that I'm still fuzzy on the particulars between "ff"
> and "fff", since I am not familiar with the sed function. I can
> certainly understand how useful these functions could be to 'pull out
> all PGP signatures' from a file (which was the Perl5 example given in
> the Oracle Linux Blog). So I can now  pull out the html "head" section
> from the page _ https://raku.org/fun/ _ (saved locally as file
> "fun.txt") using the following Raku code:
>
> user@mbook:~$ raku -ne '.put if Q[] ff Q[]' fun.txt
> 
> 
> 
> 
> Raku is optimized for fun!
>
>
> 
> 
> 
> 
>
> 
> user@mbook:~$
>
> What I'm less clear on is how the code below is functioning. I first
> print out file named "startling.txt" with 'cat':  it's supposed to
> stand in for a text delimited linewise by "header 1", "header 2", etc.
> After the 'cat' example, I show three examples with Perl(v5.26.3) and
> three examples with Raku(2020.06), generally comparing literal vs
> regex arguments.
>
> The first two Perl5 examples returns nothing; the third Perl5 example
> returns everything after the "star" line. For the Raku code, the
> 'DWIMmiest' output below is the first Raku example, which returns two
> lines, "star" and "start". This is what I expected/desired. But I'm
> not really understanding what's happening with the other 2 Raku
> examples (which return everything after the "star" line):
>
> user@mbook:~$ cat startling.txt
> s
> st
> sta
> star
> start
> startl
> startli
> startlin
> startling
>
> user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt
> user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt
> user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt
> star
> start
> user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt
> star
> start
> startl
> startli
> startlin
> startling
> user@mbook:~$
>
> I'm all in favor of improving the "ff" and "fff" functions in Raku
> over their Perl5 counterparts, but I'm hoping to gain a better
> (mnemonic?) way of remembering the expected return values with literal
> vs regex arguments.
>
> Any assistance appreciated, Bill.
>
>
>
>
>
>
> On Sun, Jul 26, 2020 at 10:04 AM Larry Wall  wrote:
> >
> > On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
> > : In the above two cases ff and fff would behave identically.
> > :
> > : The difference shines when the beginning marker can look like the end
> > : marker.
> >
> > The way I think of it is this:  You come to the end of "ff" sooner, so
> you
> > do the end test immediately after passing the start test.  You come to
> the
> > end of "fff" later, so the end test is delayed to the next iteration from
> > the start test.  (Same mnemonic for .. and ... in Perl, by the way, since
> > ff and fff were modeled on .. and ... (in their scalar form), but we
> stole
> > .. and ... in Raku for ranges and sequences so we needed something else.)
> >
> > I suppose if you're musical you can come up with mnemonics based on "fff"
> > being louder than "ff", so it echoes longer before it stops...  :)
> >
> > Larry
>

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[William Michels via perl6-users]

Thank you, Brad and Larry, for explaining the "ff" and "fff" infix
operators in Raku to me!

I have to admit that I'm still fuzzy on the particulars between "ff"
and "fff", since I am not familiar with the sed function. I can
certainly understand how useful these functions could be to 'pull out
all PGP signatures' from a file (which was the Perl5 example given in
the Oracle Linux Blog). So I can now  pull out the html "head" section
from the page _ https://raku.org/fun/ _ (saved locally as file
"fun.txt") using the following Raku code:

user@mbook:~$ raku -ne '.put if Q[] ff Q[]' fun.txt




Raku is optimized for fun!








user@mbook:~$

What I'm less clear on is how the code below is functioning. I first
print out file named "startling.txt" with 'cat':  it's supposed to
stand in for a text delimited linewise by "header 1", "header 2", etc.
After the 'cat' example, I show three examples with Perl(v5.26.3) and
three examples with Raku(2020.06), generally comparing literal vs
regex arguments.

The first two Perl5 examples returns nothing; the third Perl5 example
returns everything after the "star" line. For the Raku code, the
'DWIMmiest' output below is the first Raku example, which returns two
lines, "star" and "start". This is what I expected/desired. But I'm
not really understanding what's happening with the other 2 Raku
examples (which return everything after the "star" line):

user@mbook:~$ cat startling.txt
s
st
sta
star
start
startl
startli
startlin
startling

user@mbook:~$ perl -nE 'print if "star" .. "start" ;' startling.txt
user@mbook:~$ perl -nE 'print if /"star"/ .. /"start"/ ;' startling.txt
user@mbook:~$ perl -nE 'print if /star/ .. /start/ ;' startling.txt
star
start
startl
startli
startlin
startling
user@mbook:~$ raku -ne '.put if "star" ff "start" ;' startling.txt
star
start
user@mbook:~$ raku -ne '.put if /"star"/ ff /"start"/ ;' startling.txt
star
start
startl
startli
startlin
startling
user@mbook:~$ raku -ne '.put if /star/ ff /start/ ;' startling.txt
star
start
startl
startli
startlin
startling
user@mbook:~$

I'm all in favor of improving the "ff" and "fff" functions in Raku
over their Perl5 counterparts, but I'm hoping to gain a better
(mnemonic?) way of remembering the expected return values with literal
vs regex arguments.

Any assistance appreciated, Bill.






On Sun, Jul 26, 2020 at 10:04 AM Larry Wall  wrote:
>
> On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
> : In the above two cases ff and fff would behave identically.
> :
> : The difference shines when the beginning marker can look like the end
> : marker.
>
> The way I think of it is this:  You come to the end of "ff" sooner, so you
> do the end test immediately after passing the start test.  You come to the
> end of "fff" later, so the end test is delayed to the next iteration from
> the start test.  (Same mnemonic for .. and ... in Perl, by the way, since
> ff and fff were modeled on .. and ... (in their scalar form), but we stole
> .. and ... in Raku for ranges and sequences so we needed something else.)
>
> I suppose if you're musical you can come up with mnemonics based on "fff"
> being louder than "ff", so it echoes longer before it stops...  :)
>
> Larry

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[Larry Wall]

On Sat, Jul 25, 2020 at 04:32:02PM -0500, Brad Gilbert wrote:
: In the above two cases ff and fff would behave identically.
: 
: The difference shines when the beginning marker can look like the end
: marker.

The way I think of it is this:  You come to the end of "ff" sooner, so you
do the end test immediately after passing the start test.  You come to the
end of "fff" later, so the end test is delayed to the next iteration from
the start test.  (Same mnemonic for .. and ... in Perl, by the way, since
ff and fff were modeled on .. and ... (in their scalar form), but we stole
.. and ... in Raku for ranges and sequences so we needed something else.)

I suppose if you're musical you can come up with mnemonics based on "fff"
being louder than "ff", so it echoes longer before it stops...  :)

Larry

Re: Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[Brad Gilbert]

There's the ff operator and the fff operator.

The ff operator allows both endpoints to match at the same time.
The fff operator doesn't.

On Sat, Jul 25, 2020 at 3:16 PM William Michels via perl6-users <
perl6-us...@perl.org> wrote:

> Hello,
>
> I'm trying to learn the "ff" (flipflop) infix operator, generally
> taking examples from the docs (below):
>
> https://docs.raku.org/routine/ff
>
> I tried adding in an "m:1st" adverb and an "m:2nd" adverb, but the
> output isn't what I expect with the "m:2nd" adverb (examples #3 and
> #5):
>
> say "\n1. ";
> for  {
> say $_ if /A/ ff /B/;  # OUTPUT: «AB␤»
> }
>

You should probably use the fff operator instead

for  {
say $_ if /A/ fff /B/;  # OUTPUT: «AB␤C␤D␤B␤»
}


> say "\n2. ";
> #mine
> for  {
> say $_ if /A/ ff m:1st/B/;  # OUTPUT: «AB␤»
> }
>

I don't know why you would think that :1st would work that way.
:1st doesn't really do anything.
It makes it so that it matches at the first occurrence, which is the
default anyway.

'ABcdeFB' ~~ m:1st/.B/; # ｢AB｣
'ABcdeFB' ~~ m:2nd/.B/; # ｢FB｣

The /.B/ can match in two different places in the string, :1st makes it so
that it matches the first occurrence.
:2nd makes it match the second occurence.

At any rate it doesn't do anything special when used as part of a ff
operator.

If you wanted the 'B' to match at the first position, you need to indicate
that.
Generally you would use `^` for beginning of string.

say $_ if /A/ ff /^B/; # OUTPUT: «AB␤C␤D␤B␤»


> say "\n3. ";
> #mine
> for  {
> say $_ if /A/ ff m:2nd/B/;  # OUTPUT: «AB␤C␤D␤B␤E␤F␤»
> }


None of those strings can match 'B' more than once, so m:2nd/B/ will always
fail.
Which means that the ff operator will not stop.


> say "\n4. ";
> for  {
> say $_ if /C/ ff *;# OUTPUT: «C␤D␤B␤E␤F␤»
> }
>

Generally * matches everything.
In this case if it is on the right side of ff, it actually means don't stop.
(If it were on the left it would mean always start)

say "\n5. ";
> #mine
> for  {
> say $_ if m:2nd/B/ ff *;# OUTPUT: blank
> }
>

Again there is nothing for :2nd to match, so it never does.

I'm wondering if I'm using the correct "flipflop" operator, since
> "ff", "ff^", "fff", and "fff^" are all provided in Raku.
>

I will say that fff is slightly easier to understand, but your real failure
to understand seems to be with :2nd.


Anyway it is intended to be more like:

for < A B start C D E F end G H I J start K L M N O end P Q R S T U V W
X Y Z > {
  .say if "start" fff "end";
}
start
C
D
E
F
end
start
K
L
M
N
O
end

If you want to ignore the "start" you can use ^fff
If you want to ignore the "end" you can use fff^
If you want to ignore both use ^fff^

Same for ff  ( ^ff  ff^  ^ff^ )
And for .. ( ^..  ..^  ^..^ )

for < A B start C D E F end G H I J start K L M N O end P Q R S T U V W
X Y Z > {
  .say if "start" ^fff^ "end";
}
C
D
E
F
K
L
M
N
O

In the above two cases ff and fff would behave identically.

The difference shines when the beginning marker can look like the end
marker.

for 1..20 {
  .say if * %% 3 ff * %% 3
}
3 # matches both endpoints
6 # ditto
9
12
15
18

for 1..20 {
.say if * %% 3 fff * %% 3
}
3 # matches beginning (left)
4
5
6 # matches ending (right)
9 # begin
10
11
12 # end
15 # begin
16
17
18 # end

Learning the "ff" (flipflop) infix operator? (was Re: Raku version of "The top 10 tricks... .")

[William Michels via perl6-users]

Hello,

I'm trying to learn the "ff" (flipflop) infix operator, generally
taking examples from the docs (below):

https://docs.raku.org/routine/ff

I tried adding in an "m:1st" adverb and an "m:2nd" adverb, but the
output isn't what I expect with the "m:2nd" adverb (examples #3 and
#5):

say "\n1. ";
for  {
say $_ if /A/ ff /B/;  # OUTPUT: «AB␤»
}

say "\n2. ";
#mine
for  {
say $_ if /A/ ff m:1st/B/;  # OUTPUT: «AB␤»
}

say "\n3. ";
#mine
for  {
say $_ if /A/ ff m:2nd/B/;  # OUTPUT: «AB␤C␤D␤B␤E␤F␤»
}

say "\n4. ";
for  {
say $_ if /C/ ff *;# OUTPUT: «C␤D␤B␤E␤F␤»
}

say "\n5. ";
#mine
for  {
say $_ if m:2nd/B/ ff *;# OUTPUT: blank
}

I'm wondering if I'm using the correct "flipflop" operator, since
"ff", "ff^", "fff", and "fff^" are all provided in Raku.

Any assistance appreciated, Bill.

Re: Match operator: error with any() junction and user-defined $_ topic variable

[ToddAndMargo via perl6-users]

On 10/12/19 3:08 AM, William Michels via perl6-users wrote:

Inline:

On Fri, Oct 11, 2019 at 8:33 PM ToddAndMargo via perl6-users
 wrote:


On 10/11/19 8:09 PM, William Michels via perl6-users wrote:

Hi Todd, Per the REPL, $x looks to be a List:

mbook:~ homedir$ perl6
To exit type 'exit' or '^D'


my $x = (44,66)

(44 66)

say $x.WHAT

(List)

say $x.^name

List


my $y = < 55 77 >

(55 77)

say $y.WHAT

(List)

say $y.^name

List


say $*VM

moar (2019.07.1)

HTH, Bill.





HTH, Bill.


Sweet.  Love examples.  Thank you!

Question:  what type is "my $x = (44, 66)".   An array?



$ p6 'my List $x = (44,66); say $x;'
(44 66)

:-)



#REPL Below:

my $z = 2,4,6,8;

(2 4 6 8)

say $z.WHAT

(Int)

say $z.^name

Int

say $z.List.WHAT

(List)

say $z.List.^name

List




With the code above, you might be convinced you've created a $z scalar
holding the values (2 4 6 8) that can be coerced to a list whenever
you desire. You'd be incorrect though:


my $z = 2,4,6,8;

(2 4 6 8)

say $z

2

say $z.WHAT

(Int)

say $z.elems

1

my $a = (2,4,6,8);

(2 4 6 8)

say $a

(2 4 6 8)

say $a.WHAT

(List)

say $a.elems

4

say $*VM
moar (2019.07.1)


I guess parentheses are important in Perl 6.
Some references here (may be in need of updating):
https://docs.perl6.org/language/list
https://stackoverflow.com/questions/34997353/what-type-are-lists-of-any-type-in-perl-6
https://stackoverflow.com/questions/34997670/how-is-this-perl-sensical-considering-perl-6s-type-system

HTH, Bill.



Thank you!

--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: Match operator: error with any() junction and user-defined $_ topic variable

[William Michels via perl6-users]

Inline:

On Fri, Oct 11, 2019 at 8:33 PM ToddAndMargo via perl6-users
 wrote:
>
> On 10/11/19 8:09 PM, William Michels via perl6-users wrote:
> > Hi Todd, Per the REPL, $x looks to be a List:
> >
> > mbook:~ homedir$ perl6
> > To exit type 'exit' or '^D'
> >>
> >> my $x = (44,66)
> > (44 66)
> >> say $x.WHAT
> > (List)
> >> say $x.^name
> > List
> >>
> >> my $y = < 55 77 >
> > (55 77)
> >> say $y.WHAT
> > (List)
> >> say $y.^name
> > List
> >>
> >> say $*VM
> > moar (2019.07.1)
> >
> > HTH, Bill.
> >
> >
>
> >>> HTH, Bill.
> >>
> >> Sweet.  Love examples.  Thank you!
> >>
> >> Question:  what type is "my $x = (44, 66)".   An array?
>
>
> $ p6 'my List $x = (44,66); say $x;'
> (44 66)
>
> :-)
>

#REPL Below:
> my $z = 2,4,6,8;
(2 4 6 8)
> say $z.WHAT
(Int)
> say $z.^name
Int
> say $z.List.WHAT
(List)
> say $z.List.^name
List
>

With the code above, you might be convinced you've created a $z scalar
holding the values (2 4 6 8) that can be coerced to a list whenever
you desire. You'd be incorrect though:

> my $z = 2,4,6,8;
(2 4 6 8)
> say $z
2
> say $z.WHAT
(Int)
> say $z.elems
1
> my $a = (2,4,6,8);
(2 4 6 8)
> say $a
(2 4 6 8)
> say $a.WHAT
(List)
> say $a.elems
4
> say $*VM
> moar (2019.07.1)

I guess parentheses are important in Perl 6.
Some references here (may be in need of updating):
https://docs.perl6.org/language/list
https://stackoverflow.com/questions/34997353/what-type-are-lists-of-any-type-in-perl-6
https://stackoverflow.com/questions/34997670/how-is-this-perl-sensical-considering-perl-6s-type-system

HTH, Bill.

Re: Match operator: error with any() junction and user-defined $_ topic variable

[ToddAndMargo via perl6-users]

On 10/11/19 8:09 PM, William Michels via perl6-users wrote:

Hi Todd, Per the REPL, $x looks to be a List:

mbook:~ homedir$ perl6
To exit type 'exit' or '^D'


my $x = (44,66)

(44 66)

say $x.WHAT

(List)

say $x.^name

List


my $y = < 55 77 >

(55 77)

say $y.WHAT

(List)

say $y.^name

List


say $*VM

moar (2019.07.1)

HTH, Bill.





HTH, Bill.


Sweet.  Love examples.  Thank you!

Question:  what type is "my $x = (44, 66)".   An array?



$ p6 'my List $x = (44,66); say $x;'
(44 66)

:-)


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~

Re: Match operator: error with any() junction and user-defined $_ topic variable

[William Michels via perl6-users]

Hi Todd, Per the REPL, $x looks to be a List:

mbook:~ homedir$ perl6
To exit type 'exit' or '^D'
>
> my $x = (44,66)
(44 66)
> say $x.WHAT
(List)
> say $x.^name
List
>
> my $y = < 55 77 >
(55 77)
> say $y.WHAT
(List)
> say $y.^name
List
>
> say $*VM
moar (2019.07.1)

HTH, Bill.


On Fri, Oct 11, 2019 at 4:24 PM ToddAndMargo via perl6-users
 wrote:
>
> On 10/11/19 2:46 AM, William Michels via perl6-users wrote:
> > Below works:
> >
> > mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43'
> > (44 66)
> > any(False, False)
> > #
> > mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50'
> > (44 66)
> > any(True, False)
> > #
> > mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x
> > exists, value= $x" !! put "not there";'
> > not there
> > #
> > mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x
> > exists, value= $x" !! put "not there";'
> > x exists, value= 4
> > #
> >
> > HTH, Bill.
>
> Sweet.  Love examples.  Thank you!
>
> Question:  what type is "my $x = (44, 66)".   An array?

Re: Match operator: error with any() junction and user-defined $_ topic variable

[ToddAndMargo via perl6-users]

On 10/11/19 2:46 AM, William Michels via perl6-users wrote:

Below works:

mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43'
(44 66)
any(False, False)
#
mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50'
(44 66)
any(True, False)
#
mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x
exists, value= $x" !! put "not there";'
not there
#
mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x
exists, value= $x" !! put "not there";'
x exists, value= 4
#

HTH, Bill.


Sweet.  Love examples.  Thank you!

Question:  what type is "my $x = (44, 66)".   An array?

Re: Match operator: error with any() junction and user-defined $_ topic variable

[William Michels via perl6-users]

Below works:

mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 43'
(44 66)
any(False, False)
#
mbook:~ homedir$ perl6 -e 'my $x = (44, 66); say $x; say $x.any < 50'
(44 66)
any(True, False)
#
mbook:~ homedir$ perl6 -e 'my $x=0; my $any=2|4|8; $x==$any ?? put "x
exists, value= $x" !! put "not there";'
not there
#
mbook:~ homedir$ perl6 -e 'my $x=4; my $any=2|4|8; $x==$any ?? put "x
exists, value= $x" !! put "not there";'
x exists, value= 4
#

HTH, Bill.

On Thu, Oct 10, 2019 at 9:30 PM Todd Chester via perl6-users
 wrote:
>
>
>
> On 10/8/19 10:53 AM, Brad Gilbert wrote:
> > Most operations with Junctions produce Junctions.
> >
> >  > 1 + any(2, 3)
> >  any(3, 4)
>
> $ p6 'say 4 + any(44,66);'
> any(48, 70)
>
> Sweet!  But what would you ever use it for?
>
> Would this be the intended use: add a number to all
> values in an array?
>
> $ p6 'my @x=[44,66]; say 4 + @x.any;'
> any(48, 70)
>
> $ p6 'my @x=[44,66]; 4 + @x.any; say @x'
> WARNINGS for -e:
> Useless use of "+" in expression "4 + @x.any" in sink context (line 1)
> [44 66]
>
>
> -T

Re: Match operator: error with any() junction and user-defined $_ topic variable

[Todd Chester via perl6-users]

On 10/8/19 10:53 AM, Brad Gilbert wrote:

Most operations with Junctions produce Junctions.

     > 1 + any(2, 3)
     any(3, 4)


$ p6 'say 4 + any(44,66);'
any(48, 70)

Sweet!  But what would you ever use it for?

Would this be the intended use: add a number to all
values in an array?

$ p6 'my @x=[44,66]; say 4 + @x.any;'
any(48, 70)

$ p6 'my @x=[44,66]; 4 + @x.any; say @x'
WARNINGS for -e:
Useless use of "+" in expression "4 + @x.any" in sink context (line 1)
[44 66]


-T

Re: Match operator: error with any() junction and user-defined $_ topic variable

[William Michels via perl6-users]

Thank you very much Brad!!

Let's redirect all conversation on this particular issue here:

https://github.com/rakudo/rakudo/issues/3221

Best Regards, Bill.

On Tue, Oct 8, 2019 at 10:53 AM Brad Gilbert  wrote:
>
> Most operations with Junctions produce Junctions.
>
> > 1 + any(2, 3)
> any(3, 4)
>
> > any(1, 2) + 3
> any(4, 5)
>
> > any() ~~ /./
> any(｢a｣, ｢c｣)
>
> In the case of the following line, `$/` gets assigned a junction of the 
> results.
>
> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
>
> The `m/Hama/` is executing early in the smartmatch `~~`.
> Really you should have been using `rx/Hama/` or `/Hama/` instead.
>
> > any() ~~ m/./
> False
>
> `m//` always executes against `$_`. While `rx//` always evaluates to the 
> regex itself.
> (`/…/` will do one or the other depending on context.)
> So there are some places where `m//` appears to wait to execute like the 
> following line.
>
> > 'abc' ~~ m/b/
>
> It doesn't wait. It executes immediately.
>
>
> The reason is that smartmatch is actually a two step process.
> The above example is basically short for the following line:
>
> > (do given 'abc' { m/b/ }).ACCEPTS('abc')
>
> Now I am going to simplify it.
> The `m/b/` executes immediately.
>
> > (do given 'abc' { ｢b｣ }).ACCEPTS('abc')
> > ( ｢b｣  ).ACCEPTS('abc')
>
> Since `.ACCEPTS` on an instance of Match always returns itself, the above 
> returns the Match object.
>
> It would operate differently, but come to the same result with `rx//`.
>
> > (do given 'abc' { rx/b/ }).ACCEPTS('abc')
> > ( rx/b/  ).ACCEPTS('abc')
>
> Since `rx/b/` does indeed accept 'abc' the end result of the above line is 
> the Match object ｢b｣.
>
>
> In the case of a Junction, the `~~` applies to each part of the junction 
> separately, and then combines the results.
> So `$/` gets assigned a Junction rather than the normal Match.
> (Which means `m//` and `rx//` do not come to the same result.)
>
> If the book says that `@genus ~~ m/Hama/` and `any(@genus) ~~ m/Hama/` are 
> exactly the same, it is incorrect.
> The first sets $/ and returns the first value that returns a True value. 
> While the second returns True and sets $/ to a Junction of all the results.
>
>
> Then later when you do just `m//` it tries to assign to each value in the 
> Junction to the new result.
> Since the junction contains immutable values, that doesn't work.
>
> > $_ = 'abc';
> > $/ = any 'def', 'ghi';
> > m/abc/
> Cannot modify an immutable Str (def)
>   in block  at  line 1
>
> Basically when `m//` tries to do `$/ = …` it threads through the Junction 
> rather than just assigning directly to `$/`.
> It is a bug in the assignment code that m// uses.
>
>
> When submitting a bug report, it is best to reduce the problem to the 
> simplest example that still produces the error. The last example here does 
> just that.
> This is a compiler / runtime issue. The compiler's name is Rakudo, so the 
> appropriate repository would be https://github.com/rakudo/rakudo.
> Since you found the issue, I think you should create the issue in the bug 
> tracker.
> (Mainly because that is a common first stepping stone to getting involved.)
>
>
>
> On Tue, Oct 8, 2019 at 2:53 AM William Michels via perl6-users 
>  wrote:
>>
>> Greetings:
>>
>> I tried the following regular expression code, working generally from
>> "Learning Perl 6" by brian d foy (Chapter 15). Everything works fine
>> including the any() junction below, as long as the topic $_ variable
>> isn't defined beforehand. However specifically in combination with a
>> user-defined $_ topic variable, an any() junction returns the error,
>> "Cannot modify an immutable Match." See Perl6 REPL code below (also
>> checked with 6Pad (https://perl6.github.io/6pad/)) :
>>
>> mbook:~ homedir$ perl6
>> To exit type 'exit' or '^D'
>> > $_ = 'Hamadryas';
>> Hamadryas
>> > my @genus = < Hamadryas Sostrata Junonia >;
>> [Hamadryas Sostrata Junonia]
>> > say $_.WHAT, $/.WHAT;
>> (Str)Nil
>> > if @genus ~~ m/Hama/ { put "Matches at least one"; };
>> Matches at least one
>> > say $_.WHAT, $/.WHAT;
>> (Str)(Match)
>> > say m/Hama/;
>> ｢Hama｣
>> > say m/Hama/;
>> ｢Hama｣
>> > say $_.WHAT, $/.WHAT;
>> (Str)(Match)
>> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
>> Matches at leas

Re: Match operator: error with any() junction and user-defined $_ topic variable

[Brad Gilbert]

Most operations with Junctions produce Junctions.

> 1 + any(2, 3)
any(3, 4)

> any(1, 2) + 3
any(4, 5)

> any() ~~ /./
any(｢a｣, ｢c｣)

In the case of the following line, `$/` gets assigned a junction of the
results.

> if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };

The `m/Hama/` is executing early in the smartmatch `~~`.
Really you should have been using `rx/Hama/` or `/Hama/` instead.

> any() ~~ m/./
False

`m//` always executes against `$_`. While `rx//` always evaluates to the
regex itself.
(`/…/` will do one or the other depending on context.)
So there are some places where `m//` appears to wait to execute like the
following line.

> 'abc' ~~ m/b/

It doesn't wait. It executes immediately.


The reason is that smartmatch is actually a two step process.
The above example is basically short for the following line:

> (do given 'abc' { m/b/ }).ACCEPTS('abc')

Now I am going to simplify it.
The `m/b/` executes immediately.

> (do given 'abc' { ｢b｣ }).ACCEPTS('abc')
> ( ｢b｣  ).ACCEPTS('abc')

Since `.ACCEPTS` on an instance of Match always returns itself, the above
returns the Match object.

It would operate differently, but come to the same result with `rx//`.

> (do given 'abc' { rx/b/ }).ACCEPTS('abc')
> ( rx/b/  ).ACCEPTS('abc')

Since `rx/b/` does indeed accept 'abc' the end result of the above line is
the Match object ｢b｣.


In the case of a Junction, the `~~` applies to each part of the junction
separately, and then combines the results.
So `$/` gets assigned a Junction rather than the normal Match.
(Which means `m//` and `rx//` do not come to the same result.)

If the book says that `@genus ~~ m/Hama/` and `any(@genus) ~~ m/Hama/` are
exactly the same, it is incorrect.
The first sets $/ and returns the first value that returns a True value.
While the second returns True and sets $/ to a Junction of all the results.


Then later when you do just `m//` it tries to assign to each value in the
Junction to the new result.
Since the junction contains immutable values, that doesn't work.

> $_ = 'abc';
> $/ = any 'def', 'ghi';
> m/abc/
Cannot modify an immutable Str (def)
  in block  at  line 1

Basically when `m//` tries to do `$/ = …` it threads through the Junction
rather than just assigning directly to `$/`.
It is a bug in the assignment code that m// uses.


When submitting a bug report, it is best to reduce the problem to the
simplest example that still produces the error. The last example here does
just that.
This is a compiler / runtime issue. The compiler's name is Rakudo, so the
appropriate repository would be https://github.com/rakudo/rakudo.
Since you found the issue, I think you should create the issue in the bug
tracker.
(Mainly because that is a common first stepping stone to getting involved.)



On Tue, Oct 8, 2019 at 2:53 AM William Michels via perl6-users <
perl6-us...@perl.org> wrote:

> Greetings:
>
> I tried the following regular expression code, working generally from
> "Learning Perl 6" by brian d foy (Chapter 15). Everything works fine
> including the any() junction below, as long as the topic $_ variable
> isn't defined beforehand. However specifically in combination with a
> user-defined $_ topic variable, an any() junction returns the error,
> "Cannot modify an immutable Match." See Perl6 REPL code below (also
> checked with 6Pad (https://perl6.github.io/6pad/)) :
>
> mbook:~ homedir$ perl6
> To exit type 'exit' or '^D'
> > $_ = 'Hamadryas';
> Hamadryas
> > my @genus = < Hamadryas Sostrata Junonia >;
> [Hamadryas Sostrata Junonia]
> > say $_.WHAT, $/.WHAT;
> (Str)Nil
> > if @genus ~~ m/Hama/ { put "Matches at least one"; };
> Matches at least one
> > say $_.WHAT, $/.WHAT;
> (Str)(Match)
> > say m/Hama/;
> ｢Hama｣
> > say m/Hama/;
> ｢Hama｣
> > say $_.WHAT, $/.WHAT;
> (Str)(Match)
> > if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
> Matches at least one again
> > say $_.WHAT, $/.WHAT;
> (Str)(Junction)
> > say m/Hama/;
> Cannot modify an immutable Match (｢Hama｣)
>   in block  at  line 1
>
> > say $*VM
> moar (2019.07.1)
> >
>
> I understood from the "Learning Perl 6" book that the two smart-match
> lines of code are equivalent--the first one simply understands that
> there is an 'implied' any() junction to check the array against the
> match operator. But REPL reports back that in one case $/ returns a
> match object type, while in the other case [with an explicit any()
> junction], $/ returns a junction object type. So this feels
> inconsistent, at the very least.
>
> Any explanation appreciated. If after triaging this issue, someone
> would like me to open a Github issue, please point me towards the
> correct repository.
>
> Thanks, Bill.
>
> W. Michels, Ph.D.
>

Match operator: error with any() junction and user-defined $_ topic variable

[William Michels via perl6-users]

Greetings:

I tried the following regular expression code, working generally from
"Learning Perl 6" by brian d foy (Chapter 15). Everything works fine
including the any() junction below, as long as the topic $_ variable
isn't defined beforehand. However specifically in combination with a
user-defined $_ topic variable, an any() junction returns the error,
"Cannot modify an immutable Match." See Perl6 REPL code below (also
checked with 6Pad (https://perl6.github.io/6pad/)) :

mbook:~ homedir$ perl6
To exit type 'exit' or '^D'
> $_ = 'Hamadryas';
Hamadryas
> my @genus = < Hamadryas Sostrata Junonia >;
[Hamadryas Sostrata Junonia]
> say $_.WHAT, $/.WHAT;
(Str)Nil
> if @genus ~~ m/Hama/ { put "Matches at least one"; };
Matches at least one
> say $_.WHAT, $/.WHAT;
(Str)(Match)
> say m/Hama/;
｢Hama｣
> say m/Hama/;
｢Hama｣
> say $_.WHAT, $/.WHAT;
(Str)(Match)
> if any(@genus) ~~ m/Hama/ { put "Matches at least one again"; };
Matches at least one again
> say $_.WHAT, $/.WHAT;
(Str)(Junction)
> say m/Hama/;
Cannot modify an immutable Match (｢Hama｣)
  in block  at  line 1

> say $*VM
moar (2019.07.1)
>

I understood from the "Learning Perl 6" book that the two smart-match
lines of code are equivalent--the first one simply understands that
there is an 'implied' any() junction to check the array against the
match operator. But REPL reports back that in one case $/ returns a
match object type, while in the other case [with an explicit any()
junction], $/ returns a junction object type. So this feels
inconsistent, at the very least.

Any explanation appreciated. If after triaging this issue, someone
would like me to open a Github issue, please point me towards the
correct repository.

Thanks, Bill.

W. Michels, Ph.D.

[perl #131395] [BUG] Cross meta operator on empty list complains "This type (Scalar) does not support elems"

[Jan-Olof Hendig via RT]

On Sat, 30 Sep 2017 12:40:59 -0700, sml...@gmail.com wrote:
> 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.

Fixed with commit 
https://github.com/rakudo/rakudo/commit/6c93fde85da027748bddd7cf75e295ed70ce3b05
Roast tests added with 
https://github.com/perl6/roast/commit/7d47580eb83fbf7c315e21411422fbc547f96399

Closing

[SPAM:##] [perl #126014] Too many repetitions with xx operator causes out of memory; should it work lazily?

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Tests in
https://github.com/perl6/roast/commit/b320464868d3b8da98c090ddc4b0d57604683e13

Closing

On 2018-03-10 11:25:06, jan-olof.hen...@bredband.net wrote:
> On Wed, 22 Feb 2017 03:59:05 -0800, elizabeth wrote:
> > > On 22 Feb 2017, at 12:41, jn...@jnthn.net via RT  > > follo...@perl.org> wrote:
> > > On Sat, 30 Apr 2016 03:42:00 -0700, alex.jakime...@gmail.com wrote:
> > >> OK, I said that it only segfaults on 32-bit systems, but I was
> > >> wrong.
> > >>
> > >> Code:
> > >> 42 xx (2 ** 62)
> > >>
> > >> Result:
> > >> Segmentation fault
> > >>
> > > This is patched in MoarVM HEAD just now and no longer SEGVs
> > > (reports
> > > the array is too long to allocate). So, no longer a SEGV bug.
> > >
> > > However, I'm a bit surprised that xx does not work lazily, and
> > > actually makes such a huge array up-front. Not sure if we want to
> > > re-
> > > purpose the ticket for that; I'll remove the SEGV from the title,
> > > however, since that is resolved.
> >
> > Ah, yes, I remember we discussed this. I’ll make it a Seq, although
> > the question then becomes: should it be lazy or not? If it is not
> > lazy, we would just be postponing the exception in some cases.
> >
> >
> > Liz
>
> Fixed with commit
>
https://github.com/rakudo/rakudo/commit/1eb7b1f796214870b53c7ed055907cb29076dc78

[perl #133017] First intermediate value of reduction with zip operator

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Some extra info:

Output on all releases (not a regression because the output was always wrong):
https://gist.github.com/b4b27b8088a230a6051d634dc7b2d13e

The change in behavior happened in (2017-03-21)
https://github.com/rakudo/rakudo/commit/16f950b30572e0fa584ddfab1e84e5ef0ca5dfc9

Which links to RT#131009 ( https://rt.perl.org/Ticket/Display.html?id=131009 )


Also, FYI, we also accept bug reports on github:
https://github.com/rakudo/rakudo/issues

On 2018-03-23 07:16:22, wellnho...@aevum.de wrote:
> When using a reduction operator with the "intermediate results" option
> combined with a zip operator, e.g. [\Z+], the first intermediate value
> is wrong:
>
> say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300);
> # got: ((6) (11 22 33) (111 222 333))
> # expected: ((1 2 3) (11 22 33) (111 222 333))
>
> Reduction with hyper operators like [\<<+>>] seems to work.
>
> Only tested online on tio.run
>
> Rakudo version 2017.12 built on MoarVM version 2017.12
> implementing Perl 6.c.
>
> and code-golf.io:
>
> Rakudo version 2018.03 built on MoarVM version 2018.03
> implementing Perl 6.c
>
> Nick

[perl #133017] First intermediate value of reduction with zip operator

[via RT]

# New Ticket Created by  Nick Wellnhofer 
# Please include the string:  [perl #133017]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=133017 >


When using a reduction operator with the "intermediate results" option 
combined with a zip operator, e.g. [\Z+], the first intermediate value is wrong:

 say [\Z+] (1, 2, 3), (10, 20, 30), (100, 200, 300);
 # got:  ((6) (11 22 33) (111 222 333))
 # expected: ((1 2 3) (11 22 33) (111 222 333))

Reduction with hyper operators like [\<<+>>] seems to work.

Only tested online on tio.run

 Rakudo version 2017.12 built on MoarVM version 2017.12
 implementing Perl 6.c.

and code-golf.io:

 Rakudo version 2018.03 built on MoarVM version 2018.03
 implementing Perl 6.c

Nick

[perl #126014] Too many repetitions with xx operator causes out of memory; should it work lazily?

[Jan-Olof Hendig via RT]

On Wed, 22 Feb 2017 03:59:05 -0800, elizabeth wrote:
> > On 22 Feb 2017, at 12:41, jn...@jnthn.net via RT  > follo...@perl.org> wrote:
> > On Sat, 30 Apr 2016 03:42:00 -0700, alex.jakime...@gmail.com wrote:
> >> OK, I said that it only segfaults on 32-bit systems, but I was
> >> wrong.
> >>
> >> Code:
> >> 42 xx (2 ** 62)
> >>
> >> Result:
> >> Segmentation fault
> >>
> > This is patched in MoarVM HEAD just now and no longer SEGVs (reports
> > the array is too long to allocate). So, no longer a SEGV bug.
> >
> > However, I'm a bit surprised that xx does not work lazily, and
> > actually makes such a huge array up-front. Not sure if we want to re-
> > purpose the ticket for that; I'll remove the SEGV from the title,
> > however, since that is resolved.
> 
> Ah, yes, I remember we discussed this.  I’ll make it a Seq, although
> the question then becomes: should it be lazy or not?  If it is not
> lazy, we would just be postponing the exception in some cases.
> 
> 
> Liz

Fixed with commit 
https://github.com/rakudo/rakudo/commit/1eb7b1f796214870b53c7ed055907cb29076dc78
 

[perl #126563] [BUG] 'X' meta-operator fails with RHS input from parenthesized output of another 'X'

[Jan-Olof Hendig via RT]

On Thu, 08 Mar 2018 09:52:50 -0800, jan-olof.hen...@bredband.net wrote:
> On Wed, 04 Nov 2015 12:43:18 -0800, dhoek...@gmail.com wrote:
> > In perl6 version 2015.10-158-gbccb16d built on MoarVM version
> > 2015.10-46-g5bf7e46:
> >
> > Looking at the code for Hamming numbers at Rosetta Code found this
> > problem:
> >
> > my @z = <1 2>;
> > say  @z X*  @z  X* @z;# OK
> > say (@z X*  @z) X* @z;# OK
> > say  @z X* (@z  X* @z).Array; # OK
> > say  @z X* (@z  X* @z);  # fails
> >
> > (1 2 2 4 2 4 4 8)
> > (1 2 2 4 2 4 4 8)
> > (1 2 2 4 2 4 4 8)
> > ===SORRY!===
> > Cannot invoke this object (REPR: Uninstantiable)
> >
> > Likewise fails for other arithmetic operations (+, -, /, **), as well
> > as:
> >
> > my @y = ;
> > say  @y X~ (@y  X~ @y);  # fails
> >
> > But ','  works with both @x and @y.
> 
> This was fixed with commit a26f51361bfea213fa59749d7a401e09c8f2ef31.
> Tests needed.

Tests added with roast commit https://github.com/perl6/roast/commit/b68073aa15

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»

[perl #114554] [BUG] Definition of zero-length postfix operator wrongly allowed in Rakudo

[Zoffix Znet via RT]

On Thu, 07 Apr 2016 10:31:20 -0700, diakopter wrote:
> new behavior:
> 
> 13:30  m: sub postfix:{}($a) { say "$a bracey brace" };
> 42{}
> 13:30  rakudo-moar 61d231: OUTPUT«===SORRY!===␤Internal
> error: find_var_decl could not find $_␤»


Couple more glitches in the same area:

14:59   Zoffix  m: my $z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «5===SORRY!5=== Error 
while compiling ␤You can't adverb $z␤at :1␤--> 3my 
$z:{:42foo}7⏏5␤»
14:59   Zoffix  m: my \z:{:42foo}
14:59   camelia rakudo-moar 26522e8ac: OUTPUT: «===SORRY!===␤Cannot 
find method 'ast' on object of type NQPMu␤»

[perl #126563] [BUG] 'X' meta-operator fails with RHS input from parenthesized output of another 'X'

[Jan-Olof Hendig via RT]

On Wed, 04 Nov 2015 12:43:18 -0800, dhoek...@gmail.com wrote:
> In perl6 version 2015.10-158-gbccb16d built on MoarVM version
> 2015.10-46-g5bf7e46:
> 
> Looking at the code for Hamming numbers at Rosetta Code found this problem:
> 
> my @z = <1 2>;
> say  @z X*  @z  X* @z;# OK
> say (@z X*  @z) X* @z;# OK
> say  @z X* (@z  X* @z).Array; # OK
> say  @z X* (@z  X* @z);  # fails
> 
> (1 2 2 4 2 4 4 8)
> (1 2 2 4 2 4 4 8)
> (1 2 2 4 2 4 4 8)
> ===SORRY!===
> Cannot invoke this object (REPR: Uninstantiable)
> 
> Likewise fails for other arithmetic operations (+, -, /, **), as well as:
> 
> my @y = ;
> say  @y X~ (@y  X~ @y);  # fails
> 
> But ','  works with both @x and @y.

This was fixed with commit a26f51361bfea213fa59749d7a401e09c8f2ef31. Tests 
needed.

[perl #125618] [REGEX] Positional capture of separator on ?% operator causes compiler error

[Aleks-Daniel Jakimenko-Aleksejev via RT]

So I looked at this, and at very best the proposed error message is wrong. It
says that ? is useless when used with %%, but that's not the case:

 m: say ‘af’|‘a’|‘f’|‘’ ~~ /a? %% f/
 rakudo-moar 00af9ce27: OUTPUT: «｢af｣␤｢a｣␤｢f｣␤｢｣␤»
 m: say ‘af’|‘a’|‘f’|‘’ ~~ /a?f?/
 rakudo-moar 00af9ce27: OUTPUT: «｢af｣␤｢a｣␤｢f｣␤｢｣␤»

So yes, while in this case it is equivalent to just `a?f?`, it's not totally
useless. And I think it makes sense to allow this behavior to have all
quantifiers behaving consistently.

And according to this discussion, that particular fix will not go in:
https://irclog.perlgeek.de/perl6-dev/2018-02-11#i_15804761

On 2018-02-11 02:04:06, c...@zoffix.com wrote:
> On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
> >  m: say "ab" ~~ /^ a +% (b) $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
> >  m: say "ab" ~~ /^ a *% (b) $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
> >  m: say "ab" ~~ /^ a ?% (b) $/
> >  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> > cuid cuid_1_1436969557.11546 has not appeared␤»
> >
> > On JVM:
> >
> >  j: say "ab" ~~ /^ a ?% (b) $/
> >  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> > be used with a CodeRef␤»
> >
> > And just to show that it's not just the ?% operator alone
> > contributing
> > to the issue, but the capture too:
> >
> >  m: say "ab" ~~ /^ a ?% [b] $/
> >  rakudo-moar e4077e: OUTPUT«Nil␤»
>
>
> Made potential fix in branches in
> https://github.com/perl6/nqp/commit/ac3d5307f3 and
> https://github.com/perl6/roast/commit/f2b07afbba
>
> The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.
>
> It's blocked by 2 lines of 6.c tests that indirectly use this
> combination:
>
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-
> ae7b47444302486e790af6ee18121fabR16
>
> I delegated it to the release manager whether to merge that stuff or
> to require a fix that leaves these working and then we fix the
> compilation error itself.

[perl #125618] [REGEX] Positional capture of separator on ?% operator causes compiler error

[Zoffix Znet via RT]

On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
>  m: say "ab" ~~ /^ a +% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a *% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> cuid cuid_1_1436969557.11546 has not appeared␤»
> 
> On JVM:
> 
>  j: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> be used with a CodeRef␤»
> 
> And just to show that it's not just the ?% operator alone contributing
> to the issue, but the capture too:
> 
>  m: say "ab" ~~ /^ a ?% [b] $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»


Made potential fix in branches in 
https://github.com/perl6/nqp/commit/ac3d5307f3 and 
https://github.com/perl6/roast/commit/f2b07afbba

The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.

It's blocked by 2 lines of 6.c tests that indirectly use this combination: 
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-ae7b47444302486e790af6ee18121fabR16
 

I delegated it to the release manager whether to merge that stuff or to require 
a fix that leaves these working and then we fix the compilation error itself.

[perl #125618] [REGEX] Positional capture of separator on ?% operator causes compiler error

[Zoffix Znet via RT]

On Wed, 15 Jul 2015 07:31:55 -0700, lue wrote:
>  m: say "ab" ~~ /^ a +% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a *% (b) $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»
>  m: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-moar e4077e: OUTPUT«===SORRY!===␤QAST::Block with
> cuid cuid_1_1436969557.11546 has not appeared␤»
> 
> On JVM:
> 
>  j: say "ab" ~~ /^ a ?% (b) $/
>  rakudo-jvm e4077e: OUTPUT«===SORRY!===␤setcodeobj can only
> be used with a CodeRef␤»
> 
> And just to show that it's not just the ?% operator alone contributing
> to the issue, but the capture too:
> 
>  m: say "ab" ~~ /^ a ?% [b] $/
>  rakudo-moar e4077e: OUTPUT«Nil␤»


Made potential fix in branches in 
https://github.com/perl6/nqp/commit/ac3d5307f3 and 
https://github.com/perl6/roast/commit/f2b07afbba

The fix is to throw on `?`/`??` quantifiers used with `%`/`%%`.

It's blocked by 2 lines of 6.c tests that indirectly use this combination: 
https://github.com/perl6/roast/commit/aaa71d077431cd0a86be84bd386e1032a12e8697#diff-ae7b47444302486e790af6ee18121fabR16
 

I delegated it to the release manager whether to merge that stuff or to require 
a fix that leaves these working and then we fix the compilation error itself.

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Fri, 12 Jan 2018 03:50:19 -0800, c...@zoffix.com wrote:
> This looks to be the same issue as RT#131099. It lists a potential fix
> that fails compilation:
> https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

The fix is to throw on attempt to use list assoc on non-infixes, but
there're explosions with many other assocs; looks like anything that isn't 
unary. And
we can't throw on those, because assoc is meant to be used to disambiguate 
between
prefix/postfix that have same precedence.

It explodes in EXPR parser when trying to pop from @termstack. That area is too 
hard
for me right now, so I'm giving up on this ticket, in case anyone else wants to 
give a go...

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Fri, 12 Jan 2018 03:50:19 -0800, c...@zoffix.com wrote:
> This looks to be the same issue as RT#131099. It lists a potential fix
> that fails compilation:
> https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

The fix is to throw on attempt to use list assoc on non-infixes, but
there're explosions with many other assocs; looks like anything that isn't 
unary. And
we can't throw on those, because assoc is meant to be used to disambiguate 
between
prefix/postfix that have same precedence.

It explodes in EXPR parser when trying to pop from @termstack. That area is too 
hard
for me right now, so I'm giving up on this ticket, in case anyone else wants to 
give a go...

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Thu, 11 Jan 2018 23:40:54 -0800, comdog wrote:
> I stupidly did this:
> 
> sub prefix:<²>  ( Int:D \m --> Int:D )
> is assoc
> { m ** m }
> 
> put ²(²2);
> 
> And got this error:
> 
> ===SORRY!===
> MVMArray: Can't pop from an empty array
> 
> I figure that associativity doesn't make any sense for unary prefix
> operators but that error message is from pretty deep in the swamp. I'd
> rather have something like "Don't do stupid things that make no sense"
> sort of error.


This looks to be the same issue as RT#131099. It lists a potential fix that 
fails compilation: https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[Zoffix Znet via RT]

On Thu, 11 Jan 2018 23:40:54 -0800, comdog wrote:
> I stupidly did this:
> 
> sub prefix:<²>  ( Int:D \m --> Int:D )
> is assoc
> { m ** m }
> 
> put ²(²2);
> 
> And got this error:
> 
> ===SORRY!===
> MVMArray: Can't pop from an empty array
> 
> I figure that associativity doesn't make any sense for unary prefix
> operators but that error message is from pretty deep in the swamp. I'd
> rather have something like "Don't do stupid things that make no sense"
> sort of error.


This looks to be the same issue as RT#131099. It lists a potential fix that 
fails compilation: https://rt.perl.org/Ticket/Display.html?id=131099#txn-1455809

[perl #132711] [LTA] Stupidly using `is assoc` with unary prefix operator has an error message from the deep

[brian d foy]

# New Ticket Created by  "brian d foy" 
# Please include the string:  [perl #132711]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=132711 >


I stupidly did this:

sub prefix:<²>  ( Int:D \m --> Int:D )
is assoc
{ m ** m }

put ²(²2);

And got this error:

===SORRY!===
MVMArray: Can't pop from an empty array

I figure that associativity doesn't make any sense for unary prefix
operators but that error message is from pretty deep in the swamp. I'd
rather have something like "Don't do stupid things that make no sense"
sort of error.

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

[Zoffix Znet via RT]

On Fri, 18 Aug 2017 13:26:25 -0700, alex.jakime...@gmail.com wrote:
> Code:
> say so $*DISTRO.Str|$*KERNEL.Str ~~ /linux/
> 
> Result:
> True
> 
> 
> Code:
> say so $*DISTRO.Str|$*KERNEL.Str ~~ m/linux/
> 
> Result:
> False
> 
> 
> I'd expect the result to be identical in both cases.
> 
> IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-18#i_15039736

This now[^1] returns True for both cases, so don't understand why and
unsure whether the bug is actually fixed or if that commit just shadowed it.

[1] 
https://github.com/rakudo/rakudo/commit/8a0f6ac110b42a37a352e46c32736bac59f9ba83

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

[Zoffix Znet via RT]

On Fri, 18 Aug 2017 13:26:25 -0700, alex.jakime...@gmail.com wrote:
> Code:
> say so $*DISTRO.Str|$*KERNEL.Str ~~ /linux/
> 
> Result:
> True
> 
> 
> Code:
> say so $*DISTRO.Str|$*KERNEL.Str ~~ m/linux/
> 
> Result:
> False
> 
> 
> I'd expect the result to be identical in both cases.
> 
> IRC log: https://irclog.perlgeek.de/perl6-dev/2017-08-18#i_15039736

This now[^1] returns True for both cases, so don't understand why and
unsure whether the bug is actually fixed or if that commit just shadowed it.

[1] 
https://github.com/rakudo/rakudo/commit/8a0f6ac110b42a37a352e46c32736bac59f9ba83

[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 #124987] Roast rakudo skip/todo test:./S06-operator-overloading/sub.t line:268 reason: 'assoc(non)'

[Aleks-Daniel Jakimenko-Aleksejev via RT]

Unskipped in
https://github.com/perl6/roast/commit/5425477851ee07c5489d4647920797fe7ae01e19

[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»

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen via RT]

Further datapoints:

$ perl6
To exit type 'exit' or '^D'
> sub postfix:<€> (Int $n) {2*$n}; say 42€
84
> say postfix:<€>  (42)
84

So, the sub *does* survive from one call to the next.  It only loses the 
grammar adaptations that defining a sub postfix:<>  do.


> On 15 Aug 2017, at 21:06, Elizabeth Mattijsen  wrote:
> 
> This appears to be forgetfulness of the REPL from one input to the next.  If 
> you put it on the same line, it *does* work:
> 
>> sub postfix:<€> (Int $n) {2*$n}; say 42€
> 84
> 
> So this boils down to a much more generic issue, for which we already have 
> tickets I believe.
> 
>> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Patrick Tonnerre 
>> # Please include the string:  [perl #131900]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=131900 >
>> 
>> 
>> Hi,
>> 
>> context is :
>> MBP running macOS Sierra 10.12.6
>> RakudoStar dmg installed
>> This is Rakudo version 2017.07 built on MoarVM version 2017.07
>> implementing Perl 6.c.
>> 
>> When executing the following commands under REPL, i got that issue :
>>> sub postfix:<€> (Int $n) {2*$n};
>> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>>> say 21€
>> ===SORRY!=== Error while compiling:
>> Bogus postfix
>> --> say 21⏏€
>>   expecting any of:
>>   infix
>>   infix stopper
>>   postfix
>>   statement end
>>   statement modifier
>>   statement modifier loop
>> 
>> Running the same statements into a script is working fine :
>> #!/usr/bin/env perl6
>> 
>> sub postfix:<€> (Int $n) {2*$n}
>> 
>> say 21€;
>> 
>> ./operators.pl6 
>> 42
>> 
>> Regards
>> — 
>> Patrick

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen]

Further datapoints:

$ perl6
To exit type 'exit' or '^D'
> sub postfix:<€> (Int $n) {2*$n}; say 42€
84
> say postfix:<€>  (42)
84

So, the sub *does* survive from one call to the next.  It only loses the 
grammar adaptations that defining a sub postfix:<>  do.


> On 15 Aug 2017, at 21:06, Elizabeth Mattijsen  wrote:
> 
> This appears to be forgetfulness of the REPL from one input to the next.  If 
> you put it on the same line, it *does* work:
> 
>> sub postfix:<€> (Int $n) {2*$n}; say 42€
> 84
> 
> So this boils down to a much more generic issue, for which we already have 
> tickets I believe.
> 
>> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Patrick Tonnerre 
>> # Please include the string:  [perl #131900]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=131900 >
>> 
>> 
>> Hi,
>> 
>> context is :
>> MBP running macOS Sierra 10.12.6
>> RakudoStar dmg installed
>> This is Rakudo version 2017.07 built on MoarVM version 2017.07
>> implementing Perl 6.c.
>> 
>> When executing the following commands under REPL, i got that issue :
>>> sub postfix:<€> (Int $n) {2*$n};
>> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>>> say 21€
>> ===SORRY!=== Error while compiling:
>> Bogus postfix
>> --> say 21⏏€
>>   expecting any of:
>>   infix
>>   infix stopper
>>   postfix
>>   statement end
>>   statement modifier
>>   statement modifier loop
>> 
>> Running the same statements into a script is working fine :
>> #!/usr/bin/env perl6
>> 
>> sub postfix:<€> (Int $n) {2*$n}
>> 
>> say 21€;
>> 
>> ./operators.pl6 
>> 42
>> 
>> Regards
>> — 
>> Patrick

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Patrick Tonnerre via RT]

It works, thank you

> Le 15 août 2017 à 21:06, Elizabeth Mattijsen via RT 
>  a écrit :
> 
> This appears to be forgetfulness of the REPL from one input to the next.  If 
> you put it on the same line, it *does* work:
> 
>> sub postfix:<€> (Int $n) {2*$n}; say 42€
> 84
> 
> So this boils down to a much more generic issue, for which we already have 
> tickets I believe.
> 
>> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Patrick Tonnerre 
>> # Please include the string:  [perl #131900]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=131900 >
>> 
>> 
>> Hi,
>> 
>> context is :
>> MBP running macOS Sierra 10.12.6
>> RakudoStar dmg installed
>> This is Rakudo version 2017.07 built on MoarVM version 2017.07
>> implementing Perl 6.c.
>> 
>> When executing the following commands under REPL, i got that issue :
>>> sub postfix:<€> (Int $n) {2*$n};
>> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>>> say 21€
>> ===SORRY!=== Error while compiling:
>> Bogus postfix
>> --> say 21⏏€
>>   expecting any of:
>>   infix
>>   infix stopper
>>   postfix
>>   statement end
>>   statement modifier
>>   statement modifier loop
>> 
>> Running the same statements into a script is working fine :
>> #!/usr/bin/env perl6
>> 
>> sub postfix:<€> (Int $n) {2*$n}
>> 
>> say 21€;
>> 
>> ./operators.pl6 
>> 42
>> 
>> Regards
>> — 
>> Patrick
> 

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Patrick Tonnerre]

It works, thank you

> Le 15 août 2017 à 21:06, Elizabeth Mattijsen via RT 
>  a écrit :
> 
> This appears to be forgetfulness of the REPL from one input to the next.  If 
> you put it on the same line, it *does* work:
> 
>> sub postfix:<€> (Int $n) {2*$n}; say 42€
> 84
> 
> So this boils down to a much more generic issue, for which we already have 
> tickets I believe.
> 
>> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>>  wrote:
>> 
>> # New Ticket Created by  Patrick Tonnerre 
>> # Please include the string:  [perl #131900]
>> # in the subject line of all future correspondence about this issue. 
>> # https://rt.perl.org/Ticket/Display.html?id=131900 >
>> 
>> 
>> Hi,
>> 
>> context is :
>> MBP running macOS Sierra 10.12.6
>> RakudoStar dmg installed
>> This is Rakudo version 2017.07 built on MoarVM version 2017.07
>> implementing Perl 6.c.
>> 
>> When executing the following commands under REPL, i got that issue :
>>> sub postfix:<€> (Int $n) {2*$n};
>> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>>> say 21€
>> ===SORRY!=== Error while compiling:
>> Bogus postfix
>> --> say 21⏏€
>>   expecting any of:
>>   infix
>>   infix stopper
>>   postfix
>>   statement end
>>   statement modifier
>>   statement modifier loop
>> 
>> Running the same statements into a script is working fine :
>> #!/usr/bin/env perl6
>> 
>> sub postfix:<€> (Int $n) {2*$n}
>> 
>> say 21€;
>> 
>> ./operators.pl6 
>> 42
>> 
>> Regards
>> — 
>> Patrick
> 

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen via RT]

This appears to be forgetfulness of the REPL from one input to the next.  If 
you put it on the same line, it *does* work:

> sub postfix:<€> (Int $n) {2*$n}; say 42€
84

So this boils down to a much more generic issue, for which we already have 
tickets I believe.

> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>  wrote:
> 
> # New Ticket Created by  Patrick Tonnerre 
> # Please include the string:  [perl #131900]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131900 >
> 
> 
> Hi,
> 
> context is :
> MBP running macOS Sierra 10.12.6
> RakudoStar dmg installed
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> When executing the following commands under REPL, i got that issue :
>> sub postfix:<€> (Int $n) {2*$n};
> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>> say 21€
> ===SORRY!=== Error while compiling:
> Bogus postfix
> --> say 21⏏€
>expecting any of:
>infix
>infix stopper
>postfix
>statement end
>statement modifier
>statement modifier loop
> 
> Running the same statements into a script is working fine :
> #!/usr/bin/env perl6
> 
> sub postfix:<€> (Int $n) {2*$n}
> 
> say 21€;
> 
> ./operators.pl6 
> 42
> 
> Regards
> — 
> Patrick

Re: [perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[Elizabeth Mattijsen]

This appears to be forgetfulness of the REPL from one input to the next.  If 
you put it on the same line, it *does* work:

> sub postfix:<€> (Int $n) {2*$n}; say 42€
84

So this boils down to a much more generic issue, for which we already have 
tickets I believe.

> On 15 Aug 2017, at 14:25, Patrick Tonnerre (via RT) 
>  wrote:
> 
> # New Ticket Created by  Patrick Tonnerre 
> # Please include the string:  [perl #131900]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/Ticket/Display.html?id=131900 >
> 
> 
> Hi,
> 
> context is :
> MBP running macOS Sierra 10.12.6
> RakudoStar dmg installed
> This is Rakudo version 2017.07 built on MoarVM version 2017.07
> implementing Perl 6.c.
> 
> When executing the following commands under REPL, i got that issue :
>> sub postfix:<€> (Int $n) {2*$n};
> sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
>> say 21€
> ===SORRY!=== Error while compiling:
> Bogus postfix
> --> say 21⏏€
>expecting any of:
>infix
>infix stopper
>postfix
>statement end
>statement modifier
>statement modifier loop
> 
> Running the same statements into a script is working fine :
> #!/usr/bin/env perl6
> 
> sub postfix:<€> (Int $n) {2*$n}
> 
> say 21€;
> 
> ./operators.pl6 
> 42
> 
> Regards
> — 
> Patrick

[perl #131900] [BUG] REPL issue defining new operator with Euro symbol

[via RT]

# New Ticket Created by  Patrick Tonnerre 
# Please include the string:  [perl #131900]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/Ticket/Display.html?id=131900 >


Hi,

context is :
MBP running macOS Sierra 10.12.6
RakudoStar dmg installed
This is Rakudo version 2017.07 built on MoarVM version 2017.07
implementing Perl 6.c.

When executing the following commands under REPL, i got that issue :
> sub postfix:<€> (Int $n) {2*$n};
sub postfix:<€> (Int $n) { #`(Sub+{Precedence}|140257667062944) ... }
> say 21€
===SORRY!=== Error while compiling:
Bogus postfix
--> say 21⏏€
expecting any of:
infix
infix stopper
postfix
statement end
statement modifier
statement modifier loop

Running the same statements into a script is working fine :
#!/usr/bin/env perl6

sub postfix:<€> (Int $n) {2*$n}

say 21€;

./operators.pl6 
42

Regards
— 
Patrick