CGI, of course! :-p

Joking aside, the modules I consistently seem to have to deploy everywhere include Try::Tiny, Log::Any and LWP::Protocol::https (update: and Ref::Util). But it's not like any of these are massive or tricky to install so I don't really see a need to bloat corelist at all.

I would rather see Syntax::Keyword::Try in core. The corollary to that is that it would make sense as a feature flag, and as a core feature it could reach into internals that a CPAN module cannot (unless you're Coro).

...then I guess you'll be happy to know that it was a core feature 3 years ago, and as of v5.40, it is no longer experimental.

$ perl -E 'use v5.40; try { die "x" } catch ($e) { say $e; }'
[download]

In a world where we often work by targeting containers, and also often use tools like Carton, I don't see a big advantage to growing the core distribution. In fact I see doing so as being disadvantageous to the container paradigm. A nice slim distribution, with simple means of either bundling or pulling down what is needed makes more sense, I think.

To some degree I think that the existence in the core of modules that aren't needed for building and installing Perl and installing modules is mostly a result of inertia and a desire to maintain backward compatibility. I don't know if Hash::Util is used by the Perl install process, or to facilitate installing other modules. If not, maybe it's a candidate for exclusion from the core, except that we're kind of locked in to avoiding breaking changes. CGI was dropped from the core not only because it wasn't needed there, but because keeping it seemed like an endorsement of an antiquated programming model.

CGI was dropped from the core not only because it wasn't needed there, but because keeping it seemed like an endorsement of an antiquated programming model.

The CGI module is a GUI toolkit for web apps. It was added to the core because the web is important. Dropping it, as the web's relevance grows, makes sense to me. No not really. I would keep that for full backcompat, and add something like Mojolicious::Lite for modern web apps. :-)

I often reach for Term::ReadKey and wish it was in core as it would hardly add any bloat at all.

PDL would be nice, but very much impractical to add to the core.

I think that, while existing modules should not be removed, the criteria for adding new modules to the core distribution should be fairly strict. Particularly, I would suggest limiting inclusion of new modules to either:

1. Pure Perl modules that are both small and very widely used. If the majority of installations will be pulling a small module from CPAN, it might belong in core.

2. Modules (usually XS, but some pragmata are pure Perl) that are intricately tied to the core and are effectively "optional builtins". If the module relies to a great extent on other support within the core, it should probably be shipped with the core. I believe that Scalar::Util::weaken and the restricted hash interface in Hash::Util are examples of features in this category. Another monk mentioned Hash::Util::FieldHash, which, as I understand, requires cooperation from the core garbage collector to do its work. It is therefore closely tied to the core and should probably be maintained with the core.

Or do I misunderstand the issue?

Putting aside my possible bias in this, I do think that small parts of PDL should in fact be in the core:
• a way to do PDL's "NiceSlice" syntax extension of having a hook for array-index interpreting in user-space. Python did this to support array programming in 1995 (according to https://en.wikipedia.org/wiki/NumPy); specifically, hooks for enabling $x[0:4:2] without the current source filter shenanigans
• a heavily stripped-down PDL core that was dual-life (supplied with Perl but also upgradable from CPAN) would be a good idea too; the way to decide what would be in core would be to define small operations that would still be valuable without the wider PDL infrastructure (this would also be a candidate for a non-core "PDL::Tiny" or "PDL::Core" as its own distro)

Modules (usually XS, but some pragmata are pure Perl) that are intricately tied to the core and are effectively "optional builtins".

You mean the modules called "core extensions" in Config::Extensions?

perl -MConfig::Extensions=%Extensions -e 'for (sort{lc$a cmp lc$b}keys
+ %Extensions){print"$_\t$Extensions{$_}\n"}'
[download]

Why are some core modules referred to as "extensions"?

Sounds like a good Poll question!

Aside from that, I'd say some kind of Path::Tiny module, but one which solves the unicode filename problem at the same time. For a language that prides itself on shorthand notations, it's embarrassing to have the file operations look like the C library when it's one of the single most common needs for scripting. My preferred solution would be my proposed enhancement of the "VFS" module, but I didn't find enough tuits to get that moving.

> one which solves the unicode filename problem at the same time

What about Sys::Binmode combined with Path::Tiny?

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

I hadn't seen Sys::Binmode - that's interesting. It only solves half the problem though. From its own documentation:

Of course, in the end, we want mkdir() to receive 6 bytes of UTF-8, not 4 bytes of Latin-1. To achieve that, just do as you normally do with print(): encode your string before you give it to the OS.

use utf8;
use Encode;
 
mkdir encode("UTF-8", "épée");
[download]

That code is what you want on modern Linux systems, but who wants to write that everywhere? Meanwhile, writing that breaks Win32 support, in most cases. Perl does not currently have *any* cross-platform solution for this problem.

My point is that a person using file paths on a modern system wants to work with unicode, not mess with knowing how to encode filenames for their platform. Perl has great support for *handling* unicode, but the user experience for unicode filenames (especially on windows) is complete brokenness. I see no way to fix it while preserving back-compat, and the only solution seems to be wrapping the problem inside a module. If a module did fix the problem, then it should be core, because this is an intrinsic problem with perl that *needs* a fix.

On a sidenote, I'm baffled why Perl is so popular in Japan. I would think they'd be up against this problem nonstop, as opposed to most of Europe who can get by with Latin-1 or variants.

These are the two modules i ALWAYS have to install after installing Perl, just to make the cpan-shell usable:

1. Term::ReadLine::Perl
2. Term::ReadKey

Since they are pretty much required basics anyway for the cpan shell, they should be pre-installed. I mean, who the f*** thought it was a good idea to strip command line history from one of the basic tools needed to get a new installation up and running???

Term::ReadLine comes with different implementations and features in the backends.

The problems go way back to the very beginning when referring to GNU stuff without Perl docs were normal.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

Actually no. corelist is a frontend for Module::CoreList, which only describes "what modules shipped with versions of perl".

Since some time, the Perl developers have decided to only include in the Perl core distribution whatever is necessary to build and install Perl and to install modules from CPAN.

You are still free to create richer Perl distributions, as for example the good folks at http://strawberryperl.com/ and https://activestate.com have done. Alternatively, you can also simply create a Task:: module that lists your favourite modules.

To expect that the Perl developers care for and maintain a module that you consider good is expecting a bit too much. CPAN is available and as you already understand, recommendations change. Hence this is why the Perl core aims to only include what is needed for/by Perl itself.

For what SawyerX aims, maybe see his keynote at Perlcon in Riga - he wants to include a Moo* class constructor/accessor builder in the core. Maybe you can lobby for your other trends du jour there.

Since some time, the Perl developers have decided to only include in the Perl core distribution whatever is necessary to build and install Perl and to install modules from CPAN.

That's right, but goodies got added which aren't strictly necessary for those purposes, e.g. Hash::Util::FieldHash. I'm glad it is there (though I liked more the name choices of Alter from which it derives).

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

To expect that the Perl developers care for and maintain a module that you consider good is expecting a bit too much. CPAN is available and as you already understand, recommendations change. Hence this is why the Perl core aims to only include what is needed for/by Perl itself.

While agreeing with the lean core principle, I've seen Perl get severely eclipsed TWICE by completely inferior languages that sell themselves as a "kitchen sink" and as having "batteries included". This is about what people want and what Perl needs, not my favorite modules.

Clearly Perl is incomplete without modules or the corelist would not have over 600 items. The only question is what to include. My suggestions fall into 3 broad categories:

1. Complete Perl by bundling missing features (like a REPL)*
2. Update old interfaces and make things easier (like IO and Rule)
3. Encourage Perl use by using other languages in Perl! (FFI, Inline)


I would settle for Path::Tiny but this example from IO::All says it all:

replace this:

open STUFF, '<', './mystuff'
  or die "Can't open './mystuff' for input:\n$!";
local $/;
my $stuff = <STUFF>;
close STUFF;

with this:

my $stuff < io './mystuff';
[download]

_{* Frankly I would go wild with things like PPI, Perl::Tidy, Perl::Critic, Perl::Examples, something like Classic::Perl (expanded, for complete backcompat), B::Keywords, B::C, B::CC, Modern::Perl, etc.}

File::Find but in conjuction with a loop. It's not the same as looping over filtered results (via grep) of glob