'Here is my suggestion for an experiment: when there is a working prototype for these changes, clone CPAN and test all modules with it.'

There's no need to 'clone CPAN', smoketesters/cpantesters already provides the required functionality, anyone can smoketest cpan for any version of perl, for any OS, automatically reporting failures.

'These numbers should then be multiplied by 10x to see the effect on real code "out there".'

The number you'd end up with makes no sense at all in terms of what you seem to believe it would illustrate.

'I would prefer to see Perl first conquering Bioinformatics'

Be sure to post here when you create a group/movement working towards this goal.

'who wouldn't like to have the power of R from Perl rather than ... R'

Isn't that what Statistics::R claims to do? "Statistics::R is a module to controls the R interprete".

'I could also add making PDL more accessible, why can't its use be transparent in Perl???'

See above.

Be sure to post here when you create a group/movement working towards this goal.

There is already at least one group doing that and quite well but is not catching up IMO with other alternatives, e.g. python. I am talking about *officially* directing *funding* and man-power to this or similar projects which may have a + net-effect on establishing Perl, again, in Research, Universities, AI. (I am not affiliated with that or any other project, neither I know any of those working on them). The distinction between officially spearheading a project/direction and individually or in groups creating CPAN modules must be clear even to a not-so-well-meaning observer.

My suggested experiment is a means to assess how much potential breaks and how much effort to fix them. I said "clone" because some modules will have to be modified in order to be "fixed" for the new version. 10x is an ad-hoc multiplier to extrapolate the findings from code which has been peer-reviewed, tested and used under many circumstances by thousands (CPAN modules), to code which is private/corporate and lives in dungeons, rarely seen by more than 50 people.

Statistics::R is just a way to send and receive to an R process. It leaves a lot to be desired, e.g. getting back data structures from R, re: the omni-present data.frame. This is what I am talking about and not about reading the stdout of an R session which is trivial.

# see https://www.dummies.com/programming/r/how-to-create-a-data-frame
+-from-scratch-in-r/
use Statistics::R;
my $R = Statistics::R->new();
my $out = $R->run(<<EOR);
employee <- c('John Doe','Peter Gynn','Jolie Hope')
salary <- c(21000, 23400, 26800)
startdate <- as.Date(c('2010-11-1','2008-3-25','2007-3-14'))
employ.data <- data.frame(employee, salary, startdate)
str(employ.data)
EOR
my $frame = $R->get('employ.data');
use Data::Dumper;
print Dumper($frame);
$VAR1 = [
          'employee',
          'salary',
          'startdate',
          '1',
          'John',
          'Doe',
          '21000',
          '2010-11-01',
          '2',
          'Peter',
          'Gynn',
          '23400',
          '2008-03-25',
          '3',
          'Jolie',
          'Hope',
          '26800',
          '2007-03-14'
        ];
[download]

Typical scenario: I want to plot data just scraped with Perl using R's excellent ggplot which works mostly with data.frame. Or, I want to get statistics metrics of some other data from Perl and R provides that easily and reliably but it requires to convert R's results back to a Perl object. Which is not trivial but also not impossible. Again, I should think official support is very important for these projects. I may be naive here but the example I cite with opencv could be resolved if perl guts could be altered to scope better and keep its internals airthight. For comparison, python pandas have converters from/to R structures, e.g. data.frame.

bw, bliako

"I am talking about *officially* directing *funding* and man-power to this or similar projects which may have a + net-effect on establishing Perl, again"

"The distinction between officially spearheading a project/direction and individually or in groups creating CPAN modules must be clear even to a not-so-well-meaning observer."

How are you addressing any of your concerns that you raise? Who have you raised this with? Where is your proposal for a grant to fund this? A 'preference' without action or participation is unlikely to yield any positive results.

"My suggested experiment is a means to assess how much potential breaks and how much effort to fix them. I said "clone" because some modules will have to be modified in order to be "fixed" for the new version."

That's what the smoketesting of CPAN already does, contributes to the cpantesters data and reports failures. People report bugs, provide patches/PRs if they can. Without investigating the cause of failure, you can't estimate how long it will take to fix.

"10x is an ad-hoc multiplier to extrapolate the findings from code which has been peer-reviewed, tested and used under many circumstances by thousands (CPAN modules)"

Where is this peer-review occurring? How is this 10x relevant? You can't have thought about all of the factors involved in determining severity, or if the failure even needs to be addressed.

Regarding the "experiment" I mentioned above, here is a similar idea from the discussion at p5p cited by syphilis, posted afterwards: https://www.nntp.perl.org/group/perl.perl5.porters/2020/06/msg257591.html (comment by Karen Etheridge on June 26, 2020 18:04 - minor 1' edit tos supplement this info):

One thing that could help (and I have asked for this in the past;
unfortunately I have lacked the tuits to do it myself) is to compile
variants of perl with these pragmas forcibly turned on, and smoke all of
cpan with it to see the outcome.  As a cpan author and janitor, I would
certainly appreciate being able to see which distributions within my
control are affected by certain pragma or feature options, so that I can
proactively move to make appropriate fixes.  There may also be some
surprising findings from this exercise that would help inform us which
pragmas and features should be enabled or not enabled.  Core and dual-life
modules would also no doubt be affected, and they MUST all be fixed for
whatever default feature set is decided upon.

I think this is important. The logical next step, as I proposed, should be "measuring" the difficulty of the fixes by randomly selecting and fixing some modules and then extrapolating that figure for all Perl code "out there" using some rules of thumb not least of which: how exposed is the code to peer reviews (e.g. public CPAN module vs private/corporate) - but how to do this is a minor detail. Saying "X% of randomly selected modules were fixed 'easily' and Y% harder" is the important bit (so please no nit-picking).

bw, bliako