in reply to A "Perl-7" that I could actually USE right now
No insult is meant, of course, and “25%” is simply meant as a carelessly-discarded gauntlet. I would particularly like to see the appearance of true “compile-time checking” in Perl, within the scope of this limited and optional (but, by now, well-defined) context. I’d like to see what would basically be the equivalent of “recoding a whole bunch of stuff in XS,” but instead doing it within the main-line compiler/interpreter itself: expanding the perlguts of the thing. Yes, expanding the scope of what is “the Perl language,” but doing it in the most pragmatic way possible. There would be none of the “gee, I think this-or-that would be Cool” thinking that torpedoed the last attempt. This is the target, and we have thousands of proven tests that show what that target is, and we are going to expand the core-language implementation itself: both to optimize the runtime characteristics of this, and to facilitate compile-time checking of types, calls and so-forth to detect errors much sooner than we can now do. We are not going to change this at all. We are going to provide an entirely-optional fast track, and we are going to break absolutely nothing in the process of doing it.
Instead of debating endlessly about some –er” re-making of Perl into what it is not, why don’t we focus our efforts on streamlining a part of the system that is right now in regular daily service, and in improving our system’s ability to detect source-code errors sooner than at-runtime. This goal is fully-defined (and fully testable) right now, it has reasonable scope, and it has ROI.