Ovid

1) "." instead of "->"
2) subroutine signatures (Method::Signatures/Perl6-ish)
3) autoboxing (maybe type system)

...runner up...
4) Sane concurrency (Fibers/Coroutines)

I'd love to see a fully featured Compiler/Assembler toolchain in Perl itself that ships with Perl.

By that I mean: Not anything like the B:: family, and not something that emits .c files that can be compiled with gcc, but something that eliminates the need for gcc and as.

Reason being this would make it possible to mostly eliminate the last remaining defences people still use legitimately as to why they can't use Modules, and this defence can be "But it uses XS and I can't compile things :("

I can imagine various good things that also can be derived from having a proper compiler , but this one itch I'd love to see scratched.

( Granted, that is an epic task in itself )

Exception objects with (lazy?) stack traces, always.

Moose in core.

... I lack a third one.

Fewer obscure built-ins—there's no good reason to have raw four-argument select() built in to the language. Subroutine parameter declaration. Wordier names (or maybe just better named argument support—there's a nifty self-documenting facet to Objective-C that I miss when I go back to Perl).

Things I would add to the core language:

• An improved (meta)object system.
• Real exception handling (fix the things that Try::Tiny is papering over)
• A shared-nothing Actor style threading model.

Things I would possibly change to what is considered "Perl" but aren't core language features:

1. Better handling of modules through the entire tool chain. (Loading multiple versions, having complex dependency resolution, having the ability to easily create a shadow/mirror/mini cpan ship as a default).
2. Less modules in Core.
3. Easier to build extended-Perl distributions like Strawberry Perl.

A lot of these things are happening already. These two lists are not in any way intended to slight the people who are already working on them. I'd like to give them as much support as possible.

1) auto-dereferencing, like push $array_ref, $foo, I hate having to write @{$h->{$key}},

2) a simple way to make method calls on undef not die, sometimes when I write $element->firstchild( 'title')->nextsibling( 'p') I'd like to not die if there is no title child, the more code I have to write around this kind of construct to prevent die-ing, the more difficult it becomes to read,

finding a 3rd one would require me to think...

The arrow notation, dereferencing, Moose in core.

1. Pick an OO module as standard (try Moose).
   
2. Bundle it with perl core.
   
3. Update some standard modules to use that OO.
   
   This would nullify any "reason" to use a home grown OO

1) Cross platform XS - so deployment is easy ( you never said it had to be a realistic change ) 2) See 1 3) See 2

I really like most stuff basically :)

• OO in core (Moose or something similar instead of boilerplate).
• Better threading.
• Better deployment tools (compiler, native jar-like packaging, etc). pp is too slow on Solaris.

Runner up: - Exceptions

1) Strings always in unicode (UTF-8 preferably) 2) Real threading support (no crazy copy of all ram) 3) Rely less on global variables

1 - subroutine signatures ... anything else would require some thought ;)

1. OO in core, NOT moose ( can be Moose inspired, but shouldn't be a module )
2. Better threads
3. IPv6 (only so that we can claim we support it -- and yes, I know there's work underway)

• real signatures
• fast and native List::MOreUtils, decent tan and other small small stuff
• handling ref like in perl 6 (copy is deep, binding for aliases)

runner up: - built in dumper works deep - minimal moose in core - file slurping with "lines" a la perl 6, ok we habe IO::All

Also, remove the insanity of having to predeclare every feature you wish to use. Strict, warnings, 5.10, 5.12 etc etc.

1) no bugs (http://bugs.perl.org) 2) runs faster and uses less memory 3) reverse debugging support (step forward, step backward in "perl -d")

Anything else I would like to change (OO, method signatures, etc.) is already possible thanks to Moose!

I would say "saner utf8 behaviour" but I'm not sure I know what that behaviour should be. With all the utf8-related code already written in the world the sanest thing Perl can do with utf8 is probably CHANGE NOTHING. Sigh.

Looks like my (2) is in 5.14 too!

Faster: http://search.cpan.org/dist/perl-5.14.0-RC1/pod/perldelta.pod#Optimisationofshift%28%29andpop%28%29callswithout_arguments

Less memory: http://search.cpan.org/dist/perl-5.14.0-RC1/pod/perldelta.pod#@_usesless_memory

Awesome :)

1. Better and much easier Perl C/C++ interoperability and integration. CTypes for Perl (as chromatic mentioned) and things like a Boost.Perl C++ integration library like there is for Python

2. OO standard in core

3. Ability to pre-compile Perl ie. .pl to .plc separate from running interpreter

(1) overhaul the package/module/namespace system

(2) more clearly distinguish text and byte strings

(3) give hashrefs and blocks unambiguous delimiters

@rjbs: do we get auto-dereferencing in all cases? From what I have read it's done for some constructs, indeed like push, but AFAICT it doesn't happen everywhere you can have an array (map/grep, foreach...). I would love to be wrong though. And in any case that's a welcome improvement.

But since you got me thinking... I'd also like in-line subs please. Sometimes the clean way to write the code is a tad slow.

1. 1) . instead of ->
2. 2) better plotting (or at least easier to install plotting libraries that the modules use)
3. 3) slightly better module install (see 2 regarding installing PDL and the plotting modules it uses...). There is an interactive part for some of the modules and it does go well.

gizmo

I would like to see the removal of the rarely-used functions from the core. Things like the get... functions and bit manipulation. They can have their own modules.

In order of preference:

. a MOP to make Moose faster, and compatible with other object systems; . Method::Signatures builtin; . sane shared-nothing concurrency.

Runners up:

. CTypes for easier (no XS) access to std C libs; . a JIT: I would gladly trade some parts of Perl for a JIT.

I wish to add these modules to Perl core:

* Moose * Try::Tiny * Log::Dispatch

and a modern threading system (something like in Perl6) and a "multiprocessing" module (similar to Python)

a) Do not fall at OO-only core modules in a near future. Provide dual interfaces to same functionality or something like. Do not fall in create objects and read 6 files to start a simple task. ...

b) Still better performance in general...memory footprint and usage, platform specific tweaks, etc

c) Still better core: better POD functionality, better core POD contents, better common core components, better multi-platform functionality in core, UI helpers or at least renew console and term shipped functionality... plack? an httpd? a demon launcher? etc. CGI is ok in core for backward compatibility, but needs some young roommates. I emphasize "common" because not everything in the world is web, neither OO bloatware.

Thanks for ask for opinions.

1) remove use utf8; because Perl will be utf8 compliant. ALL processing in utf8 (or unicode codepoint like now)

2) A clear separation of byte stream scalar and character stream scalar

3) Don't fear to deprecate features.

1. 1. Modern OO built in to the compiler. Not the hackjob add on we have now that is slow and has a lot of dependencies if you want full functionality (sorry, Moose is great work, the problem is not with its design but the limitations of the perl5 compiler).
2. 2. A sane way of deploying dependencies. PAR, cpanm and local::lib are nice in their own way but don't really cut it in a corporate environment when you have to deploy system shareable libraries like glibc, libgd and have it work for non-sysadmin programmers. I'm bored of being hit with the TCO hammer by tech architects who get to choose what languages I can use.
3. 3. A way of parsing perl5 without having to use the perl5 compiler (I can wish). Betcha that's one of the main reasons the Google guys never got it to run safely in a sandbox on AppEngine.

TBH looking at the above the only realistic answer is going to be *port perl6 to run on the JVM* and port the valuable bits of Perl5 CPAN to CPAN6, while making CPAN6 handle historical deps easily in the way that CPAN5 does not.

I know that Parrot is register-based and the JVM is stack-based but as of JDK 7 (out now) consider that JSR 292 has added support for dynamically-typed languages http://openjdk.java.net/projects/jdk7/features/#f353 and to judge by what Jonathan Worthington blogged back in January about perl6 on the JVM http://6guts.wordpress.com/2011/01/16/nqp-and-6model-big-steps-forward-on-parrot-and-jvm/ it doesn't seem so outrageous that we could achieve that.

The alternative is people will move over to Java or Clojure or JRuby or (insert trendy language du jour here). "What, Java?!" do you say? Assuming JSR 335: Lambda Expressions http://www.jcp.org/en/jsr/detail?id=335 is delivered in JDK 8 http://jcp.org/en/jsr/results?id=5110 then you will be seeing first-class functions and closures natively in Java 1.8 http://www.javarants.com/2011/01/22/using-closures-method-handles-and-extension-methods-in-java-8-jsr-335/

Food for thought, anyway. -Peter

1) JAR-like deployment 2) Ctypes 3) Native fast MOP primitives

I just remembered my third problem with perl that i'd change so much if i could:

Subroutine calls of any manner are way too expensive. Often when tweaking performance out of applications for me it boils down to inlining subroutines and making my code ugly.

That's terrible and i'd love to see that changed.

• optimize class lookup (by ptr and certainly not by name at run-time as now). class support is insane.

• core support for types (typed hashes and arrays for a start). See my "use types" blog entry.

• optional function declarations or a better function compiler to get rid of unneeded @_ and markstack handling. make function and method calls saner.

• core support for B::Generate. This is the base block for every optimization, if not adopted by core.

• const optimizations (readonly vars)

• get rid of xpv* helper structs, which cost another indirection and only help with type upgrades to keep the same SV ptr. Have no idea how though as it will cost memory. Maybe just reserve 6 slots (PVMG) and indirect only on the bigger types. So we will have 10 SV slots instead of 4+(4-6).

I'll have more time to do the compiler, types and later dump/undump - a linker in perl. But modules cannot be dumped, just states. modules can only be pre-compiled.

Jit can be avoided by gerard goosens's patch.

• $this or $self on method calls, instead of first parameter or a reliable way to detect whether a sub is called as a method or as a function

• Nested subs ought to work as in Javascript (local visibility, accessing the variables of the current call)

• Remove the ugly braces around object attributes; direct access to attributes should go through a hidden layer of accessors if one is implemented (creating accessors by hand is the yuck!)

Prototypical OO A good REPL CTypes

(and is anyone ever going to fix this infuriating comment system?!)

• strict (vars at least) and warnings by default

Honestly, can't come up with two more without reading up or thinking about it, I'll do both and come back.

Okay,

• try::tiny in core would be nice

That's all I got.

Almost everyone here is adding the same predictable things... "real" OO, without defining what that means, and function/method prototypes/signatures, as a way of unpacking arguments. That's not what I'd like to see.

What I'd like to see is the idea started by the pluggable keywords API, extended a lot more. Create a mechanism for pluggable keywords to be invoked, not at the surface characters of the syntax of a perl source-code file, but at strategic points in the parse tree of a perl program.

I'd like to see optrees expressable as Perl-accessible object state, in ways that can be easily inspected, manipulated, and generated by Perl code.

Finally I'd like to see a chunk of CPAN carved up for making modules out of these two features. Adding someone's idea of objects, or function parameters, or whatever, to the core is not going to fly all that well against years of Perl being the mechanism, not the policy. But with easy and powerful support for extending the Perl parser like this, objects or function signatures or whatever could easily be added by some CPAN author using only a small bit of pure perl code.

The split between Perl and CPAN is that Perl is the mechanism by which you can create your policy and put it on CPAN. CPAN succeeds -because- Perl keeps its nose out of the policy of things, happy to sit there in the base level providing whatever mechanism is required to implement that policy.

Were Perl core to have had, say, one core way of doing asynchronous event loops, we wouldn't have the AnyEvent/IO::Async/POE and friends, that we have on CPAN.

In changing these three things, I would most like to emphasise keeping one thing the same: that Perl be a mechanism, supporting the collection of policies found on CPAN.

1. LISP-stylee macros.

2. Ability to have multiple versions of modules installed.

3. A text/character encoding system that doesn't confuse the hell out of me.