You asked, they answered. You meaning those posting questions on last week's article, and they meaning Larry Wall and Damian Conway (with a bit of help from Dan, Jeff, Hugo, and Nat).
Extensions
by djberg96
How will writing C extensions in Perl 6 compare to Perl 5 (XS)? Will it be easier? Will I be able to interface to external libraries without all this XS/extension stuff?
It's hard to imagine us making it harder to write C extensions. We're fiendish, but not that fiendish!
The Inline family of modules demonstrated convincingly that it's perfectly possible to integrate foreign code into Perl with far less pain than XS requires. We'd certainly like to make that just as easy in Perl 6.
Moreover, Parrot will provide a much cleaner OO API to the underlying data structures of Perl 6, while Perl itself will have a type system that can specify low-level interfaces. So there won't be any need for intermediate languages to connect Perl and C.
Objects, context, et al
by djberg96
Will Perl 6 allow a programmer to distinguish [the desired return type] from within a method? Will there be better support for method chaining, along the lines of Robin Houston's 'Want' module?
Robin's excellent Want.pm module is based on an RFC proposal to greatly extend the number of calling contexts that Perl subroutines can detect.
As long as such a context discovery mechanism does not impose extra subroutine call overhead, Larry is in favor of it, so we'll almost certainly see some variant of it native in Perl 6. Note, however, that some of the need for a want function could go away if overloading takes return types into account.
Ease of parsing Perl 6
by VSarkiss
The (true) comment is often made about Perl 5, "Only Perl can parse Perl". It appears Perl 6 will also have many nice DWIM-y features, some of which depend on interpreting input flexibly. I like that a lot, but I also wonder how much weight is being given to making Perl 6 easy to parse; without resorting to tightly coupling the scanner and parser, for example.
Ease of parsing has certainly been an important consideration in designing Perl 6. But never the prime consideration. DWIMmity always takes precedence.
That said, we fully expect that a substantial portion of the Perl 6 parser will be written in Perl 6 itself. Which implies that we want to (a) make Perl 6's syntax simple enough that Perl can parse itself, and (b) make Perl's parsing capabilities sophisticated enough that Perl can parse itself.
Oh, and it's not clear that Perl 6 will even have a separate scanner and parser. It may well be that the parsing technology it uses is more like the "on-the-fly" tokenisation provided by Parse::RecDescent.
Much will be revealed when the next Apocalypse ("Regexes and Parsing") appears in the coming few weeks.
Better defaults?
by strat
Hello, very often, I notice beginners having problems with interpolation
of variables in regexes, especially if there are "strange" chars, e.g:
c:\work> perl -w
$match = "\\";
$string =~
because they often forget \Q$match\E or the like.
In my eyes, changing the default-behaviour to no-auto-evaluation it will make it easier for beginners to not writing programs that accidentally work, because just by changing the content of a variable, you might get syntax errors, or much stranger, unicode errors. Perhaps using \E....\Q or the like explicitly for auto-evaluation?
Larry doesn't like \Q$match\E either -- not just because the default behaviour is the wrong way round but also because it's gratuitously ugly. So Perl 6 regexes will assume that an ordinary interpolation is to be matched exactly, and you'll have to use special syntax to "call" a regex in a variable, probably something resembling:
$string =~In fact, there won't ever be any interpolation in Perl 6 regexes. Variables are remembered but not evaluated during the regex parse. Then during regex evaluation, the variable is either matched exactly or as a sub-regex depending on how it was invoked. Interestingly, this also lets us do away with \1 and replace it with $1, since the variable $1 can now match exactly as the backreference \1 does in Perl 5.//;
These changes are all part of a drive to make regexes much more readable. A major goal for Perl 6 is to break backward compatibility in the areas that need it, and no area needs it more than regular expression syntax. So prepare yourselves for a certain amount of future shock when you read Apocalypse 5, because we're going to propose a radical re-design of regex metacharacters. We think you'll like it. Eventually.
Platform specific functionality (alarm/fork) etc.
by osfameron
Some core functionality of Perl is OS related. alarm, fork, flock, signal handlers etc. i.e. with Perl 5, they aren't fully implemented on the Win32 platform. It is argued that this is because of insufficiencies in the OS, but they are part of the language, and I'd argue that they should work as much as possible on all platforms.
With Perl 6, will these be natively implemented within the language (e.g. within the capabilities of Parrot I suppose)? Or would they be transparently wrapped? Or will Win32 etc. users still have to make do with the non- or partially- implemented versions? (I'm hoping of course that we will be able to play with the big boys soon!)
Most OS-specific interfaces are getting kicked out of the language proper, though they'll be readily available as standard modules.
It's a matter of ongoing research as to what's the best way to handle portable system programming. Some of these interfaces ought to be emulated where the OS doesn't provide support, but other interfaces should simply be superseded with a better way to do it everywhere. For instance, fork can be emulated (and is already emulated in Perl 5 on Windows). But even though it's possible to emulate alarm, we almost certainly won't. It's a really lousy interface for timing things, and we ought to be able to do better.
The problem with simple interfaces is that sometimes they're too simple. The original Unix syscall API is showing signs of strain now that modern versions such as Linux are more complicated than Multics ever was. Nowhere is it more true that easy things should be easy, and hard things should be possible.
Signals, eval, exceptions
by djberg96
Is the $SIG{__DIE__} and $SIG{__WARN__} & eval issue worked out? Or will that whole mechanism be replaced with a try/catch/throw/finally approach?
In Perl 6 when you want to intercept the propagation of exceptions you'll use CATCH blocks. And when you want to intercept the creation of exceptions, you'll redefine the appropriate die method. You might choose to do that universally, by redefining &UNIVERSAL::die or &*die, or you might choose to only do so for a particular exception class (say X::Overflow::die).
In a similar way, to change how warnings are created, you would redefine (perhaps globally, perhaps lexically, perhaps dynamically) the appropriate warn method.
Tainting, Safe compartments, Security
by ziggy
A few questions, all somewhat interrelated.
The only really big change to tainting is that it's no longer a special built-in property of data, but simply another instance of the general property mechanism of Perl 6. That does mean that it's easier to untaint data by force, but since individual filehandles can be marked as tainted or untainted, there will be less need for forceful untainting, and perhaps we can keep it culturally taboo to untaint data without checking it thoroughly.
Safe compartments are fine as far as they go, and Perl 6 will offer a thread-based model of sandboxing -- that is, the ability to execute untrusted code. But tainting is fundamentally different from sandboxing. It's running untrusted data through trusted code. That's been a unique feature of Perl for many years, and we're not about to break something that Perl already does right.
As for BEGIN blocks, there's no single point at which you can
intercept them because BEGIN blocks run the moment they're compiled, by
definition. And intercepting BEGIN blocks themselves is not quite the
right solution, though it's on the right track. Perl 6 will generalize
the concept of BEGIN blocks, so that you can define any identifier to
take a closure and (at compile time) store that closure somewhere in
the program for later execution. You might store such a closure as a
property of the current lexical scope, or as a property of some
variable in the current scope. So not only will we have pre-defined
blocks such as CATCH and LAST that execute at particular times, but we'll
also allow user-defined blocks to be evaluated whenever the user
chooses to evaluate them. The only constraint is that they cannot run
earlier than a BEGIN block would. That is, they cannot run before
they're defined. Maybe in Perl 7...
There will certainly be access to the various stages of parsing and running code from within Perl, and the old eval STRING will be defined in terms of these primitives. There's no reason why a checker couldn't be built into that, or into any other construct that incorporates code into Perl. The only real question is to what extent the Parrot assembly language will turn out to be amenable to such security analysis. But that's a Parrot question, not a Perl question.
Pascal-like "in" operator?
by hrothgar
It may be too late for this, but will there be a Pascal-style "in" operator? It would be nice to be able to do this: &some_sub if ("some_string" in @some_array);
The new "smart match" operator will handle this. Smart-matching a scalar against an array succeeds if any element of the array individually smart-matches the scalar. So you'll be able to say:
some_sub() if "some_string" =~ @some_array;
There's also a chance that Perl 6 will have superpositions, so you'll be able to specify even more exact inclusion tests:
print "numeric match" if $var == any(@some_array);
print "string match" if $var eq any(@some_array);
print "new minimum" if $var
Notice that the last example took advantage of the smart-match operator as well.
Will it be released this decade?
by chicks
I'm curious how long a time frame people foresee for Perl 6. I know that any such
schedule is probably totally optimistic and guesswork, but it'd be nice to have some idea
what the people in the know foresee. When might the Larry's specs be done? When
might we start to see early implementations of those specs? When might a release
candidate come out? This would be an even more fun process if everybody jotted down
their own answers without consulting the others.
What, and let Larry rig it so that he wins?
We're pushing the design along as hard as we can, but our first
concern is to get Perl 6 right, rather than just get it done.
Expect to see the bulk of the design finalized in the next twelve months,
with alphas and betas starting to appear towards the end of
that timeframe.
Estimates of 2005 to 2008 (based on extrapolating the progress so far)
are, of course, way off beam. They're ignoring one essential factor -- that
the first half dozen or so Apocalypses specify the bed-rock of the
language: data types, operators, flow control, regexes, modules, OO.
Once that foundation is in place, most of the rest of the design falls out almost
trivially from the constraints that have already been laid down.
Making those fundamental design decisions is very slow -- because we
have to look forward and take everything else into account -- but
once that's done, the rest of the design can be drawn together
comparatively quickly.
POD
by slagel
Is POD still going to be around? Are there any plans to add a javadoc style documentor
to perl 6 that can do introspection on your perl modules?
POD is definitely still going to be around. And enhanced.
A single source file will be able to contain multiple separate POD streams,
all of which will be accessible from the program itself.
For example, the __DATA__ section of a program will become
just another POD stream. So you'll be able to have multiple virtual
files in your source, without needing to use trickery like
Inline::Files.
POD will also become modular. You'll be able to specify something like:
=use StdDisclaimer.pod
rather than cutting and pasting the same piece of POD into every document.
And, yes, we're intending to provide much better support for metadata and
code introspection, so that modules can document their API with far less
effort.
Practical Questions
by Purdy
If you're a Perl 4/5 novice, how much re-learning are you going to undertake
to be at the same level with Perl 6?
Well, if you're a novice in Perl 5, it won't be hard to get to the same level of
inexperience in Perl 6. ;-)
But seriously, apart from a few syntactic changes (->
becoming ., . becoming _, sigils becoming
invariant), everyday Perl 6 will look
an awful lot like everyday Perl 5.
And many of the changes we're making to the language are designed to
make it easier to get started, easier for novices to understand what's
actually going on in their programs. Invariant sigils are especially
important there. And subtle changes such as @ARGV becoming
@ARGS. And removing most of the magic global punctuation
variables. And eliminating quite a number of the obscure and/or implicit
behaviours (e.g. split in a non-list context).
That's not to say that there won't be new things to learn. If you want
to write classes, you'll definitely want to learn the new streamlined
OO notation. And we hope that some of the biggest differences in
everyday programs show up within regular expressions, because that's an
area where the entire culture of Unix needs a cleanup, not just Perl.
Module support
by lini
Will there be any supported added to allow
multiple versions of the same module to be installed? This would make it easier to roll
out a new version without having to regress all of the Perl scripts running on the box.
This is a very high priority. Perl is now used in huge production environments, where a
company may need to simultaneously use and support several incompatible versions of a given
module running under several versions of the interpreter.
In Perl 6, the version number (and the author's name or CPAN identifier) will be
part of the module's full name. So you will be able to say something like:
use RTF::Converter:3.0.0 'read';
use RTF::Converter:4.0.0 'write';
in a single program and load both versions of the module at once.
An even more likely scenario is that two modules you're using require
two different versions of some third module. To avoid the Perl
equivalent of ".dll hell", we'll be doing pretty much the same thing
that .NET does with its modules. We hope we're honest enough to steal
good ideas from wherever we find them.
Source Filters
by pdcawley
In perl 5, source filters will only work if the modules they apply to are used during the
initial startup phase of Perl's execution. If you do a runtime require of a module then its
source filters don't get applied. This is somewhat annoying. (And that's putting it mildly;
the whole BEGIN/CHECK/INIT cycle only works at perl start time, which makes
delayed loading of all sorts of modules impossible.)
So, assuming perl 6 retains BEGIN/CHECK/INIT and source filters (and I hope it does),
will these now work for modules that get loaded after the startup phase?
There's no particular reason why source filters can't be made to work
whenever the source in question is about to be compiled.
However, a lot of what people are doing right now with
source filters would better be handled by grammar munging,
particularly those source filters that have to preparse the Perl code.
Part of the regex redesign is to allow Perl to be parsed by a system of
Perl regexes (i.e. by a grammar). Grammars in Perl 6 will be objects
of a class where the methods define the individual grammar rules. So
it will be easy to override or add to a particular grammatical rule.
Such grammatical changes will be declared in a lexical scope, which means
you won't have to worry about someone clobbering your module's grammar
from elsewhere.
So if you really, really want BEGIN blocks to behave differently, you
can in fact intercept them all at one point -- just rewrite the grammar.
And then document the heck out of it!
Which modules?
by broquaint
Can we expect all of the standard modules in the current perl distro to appear in perl6,
and what, if any, new modules are likely to appear alongside the first release
(Parse::Perl) ?
It's highly unlikely that all the standard Perl 5 modules will appear in Perl 6. Some of them
(e.g. Class::Struct, Math::BigFloat) will be redundant, since Perl 6 will provide the same or better
functionality built in. Others (e.g. English, Symbol, fields) will be redundant because Perl 6 will
have removed the warts they're supposed to bandage. Still others (e.g. Text::Soundex, Socket)
are now only of interest to a small minority of Perl's 21st Century constituency. It's
unlikely any of them will be standard in Perl 6.
As for new modules in the standard distribution...they're unlikely too. In fact, it's
entirely possible that Perl 6 will ship with no standard modules, or perhaps
only a very small number of "essentials". The problem is that it's nearly impossible to
get any kind of general agreement on what constitutes a "standard" module. Everybody
knows what set of extensions they personally consider essential to have on every
machine, but the union of those sets is most of the CPAN!
It's impractical to ship Perl 6 with a thousand modules, so we're seriously considering
shipping it with almost none, and instead making the process of downloading and installing
appropriate SDKs highly safe and transparent.
Perl design goals
by lini
Other than "Do What I Mean", removing the cruftiness from past Perl
implementations, and adding new cool stuff, can you describe the basic design goals
underlying the design of Perl 6?
Although the Apocalypses are good at organizing the changes into specific areas, I feel
like I'm missing the overall picture -- what objectives are planned for the language
redesign of big-P Perl? (as opposed the compiler/virtual machine redesign in small-p
perl)
Ooh, great question. There are several fundamental design goals for Perl 6.
- Throw out the prototype, just this once. We've maintained backward
compatibility through 15 years of evolution, and it shows. Interviewers
inevitably ask Larry: "If you had to do it all over, what
would you do differently?" Perl 6 is the answer to that. We've decided
to take a leap of faith and assume that we can translate Perl 5 to Perl
6. Given that assumption, or presumption, we've chosen to really and
truly redesign everything based what we've learned from the prototype,
both good and bad. We want to keep everything that leads to joy, and
leave behind everything that leads to grief. We want to design "the
perfect language".
- Recognize that we cannot design a perfect language. First,
because there is no such thing, and second, because we aren't smart
enough to completely think through such a thing, and third, because
even if we were smart enough, we still wouldn't know enough about the
future. But one of the things that has always make Perl great is its
ability to evolve and migrate into new problem spaces. So a
fundamental design goal of Perl 6 is to increase the evolvability of
Perl. Hence the mutable grammar, and the simplification of closure
syntax to make it suitable for defining new constructs, or redefining
old ones.
- Evolve Perl's evolvability. Beyond the ability to evolve Perl
itself is the ability to evolve solutions
written in Perl. Among other things, this involves the scalability of
solutions in Perl. The user must be able to start quick-and-dirty
and grow the program into a robust large system. Users must
be able to switch programming styles, paradigms, and methodologies as
they refactor their programs in the light of new requirements. Perl
must not only be an example of, but must also support, Extreme Programming.
- Optimize Perl's complexity. There is complexity that maps
onto the problem, and complexity that doesn't. We're endeavouring to
maximize necessary complexity while minimizing gratuitous
complexity. That means looking for the big simplifications that unify
complexity, so that users only have to learn the complex bits once.
So, for example, we unify the semantics of the =~ operator
and switch statements. We unify the syntax of switch statements and
exception handlers. We unify the declaration of exception handlers
with BEGIN blocks. The RFCs contain many good ideas, but without the
unification principle we'd end up with
second
system effect (or worse). "There's More Than
One Way To Do It" does not mean there should ten ways to do it.
Somewhere between two or three ways is generally the right fractal
dimension to aim for.
- Recalculate the Huffman coding. Easy things should be easy,
and hard things should be possible. Perl 5 was a good approximation,
but there are many things that should be easier. There are also
a few things that should be harder (because you can't shorten some
things without making something else longer). For example, it will be slightly
harder to do some of the things that Perl 5 does with punctuational
variables, but by changing that we find that we can have a $(...)
syntax that makes expression interpolation much easier.
- Stay natural. We constantly have to keep in mind why natural
languages are good at what they're good at. And to never forget that Perl
is a human language first, and a computer language second. The temptation
is to pretend that a language is a work of art. But it isn't; it's an
artistic medium, to be used for good or ill by the artist. We need to
allow precision, but also allow imprecision, because both are useful.
And never for a moment allow ourselves to think that the Perl language
is more important than the Perl culture. A language without a culture
is dead.
Hmmmmmm...there's probably a master's thesis in each one of those.
Favorite?
by ChrisDolan
To what change are YOU most looking forward?
Part of the regex redesign is to allow Perl to be parsed by a system of Perl regexes (i.e. by a grammar). Grammars in Perl 6 will be objects of a class where the methods define the individual grammar rules. So it will be easy to override or add to a particular grammatical rule.
I never realized this was the plan before. This strikes me as a truly revolutionary idea, and I'm guessing that in five or ten years, all major interpreted "scripting" languages will be going this route.
The possibilities are going to be dancing in my head for a long time to come.
Re:The best part
raptor on 2002-05-21T11:47:39
yeah... that is the "rockiest" part.... i was wondering long time how this parsing will be done... now i get some idea..
To avoid the Perl equivalent of ".dll hell", we'll be doing pretty much the same thing that.NET does with its modules. We hope we're honest enough to steal good ideas from wherever we find them.
Can someone please expand on that? What does
I must be missing something obvious, because I've never had a problem similar to the one this is solving. If some application requires a specific version of a module, @INC is your friend... or isn't it?
Re:Multiple module versions?
Matts on 2002-05-21T08:36:21
Say you have a single application with two modules, a Config parser and an XSLT template engine both using XML - one module uses XML::LibXML's 1.3x API, and one uses XML::LibXML's 1.5x API (they differ slightly, unfortunately). Maintaining a separate @INC isn't really possible in that situation.
However I'm not sure how they hope to solve this at the linker level for XS (or whatever that becomes) modules. It will certainly be interesting to find out.Re:Multiple module versions?
Elian on 2002-05-21T14:27:13
We can't solve it at the linker level for other people's C code. For our extensions, yes, but not for other people. So you may be able to use multiple versions of, say, DBD::CSV in your perl program at one time, but not multiple versions of DBD::Oracle.
Separately, of course, it's easy assuming that you've independently named libraries. Having two, or three, or ten, versions of GC in your perl tree's no problem if gd.so has versioned names (or you linked statically), you just may not be able to use them at once.Re:Multiple module versions?
jdavidb on 2002-05-21T09:10:05
I am assuming (based on the statement that modules will basically include the version number as part of the name) that it is similar to what UNIX does with shared libraries (.so's), and thus perhaps
.NET's inventors were honest enough to steal good ideas from wherever they found them. :) All I can say to the designers is, thank you, thank you, thank you, thank you! A coworker's been giving me grief over module versioning for awhile now, and it's started to bother me as well.
As for using @INC to get to the module version you want, that's a great alternative, until you get to this:
myapp.pl wants to use the GoodApp.pm module. GoodApp.pm uses AppHelper.pm and TMTOW.pm. AppHelper.pm makes extensive use of DWIM.pm version 1.37. TMTOW.pm also uses DWIM.pm, but unfortunately it was written against an older version 0.29. DWIM.pm's interface has changed substantially between the two versions, but in this case, both versions need to be loaded at the same time in the same application space.
See what I mean?
:) Re:Multiple module versions?
Matts on 2002-05-21T11:27:28
Of course UNIX's.so solution doesn't solve the above problem, as you get symbol conflicts. Re:Multiple module versions?
jdavidb on 2002-05-21T11:52:56
My lack of sleep is showing, isn't it?
:) (Or more likely, lack of experience. Never got that far into .so's after I discovered Perl.)
Re:Will Perl6 be Ruby?
jdavidb on 2002-05-21T10:17:52
All you have to do is hack the grammar; it can be any language you want!
Okay, maybe that's going too far.
:)
Re:more questions
podmaster on 2002-05-22T00:43:33
Does it really matter? (the functionality will be available, it only makes sense to put it in a module -- i'm pretty sure that's where it will end up, who wants a bloated perl)it was mentioned that Parrot will allow freezing/thawing stuff ? will there be keywords for this or it will be separate modules like it is today with Perl5 ?I'm not familiar with List or Prolog. What exactly do you mean? In Perl6 the entire program will be available to itself ( the program ). Every { BLOCK } will be turned into a closure, and every pod BLOCK into a stream. You can manipulate each as you see fit. Also, eval will still exists... does that clear it up for you?One last thing may be not in the context of all this i was wondering... one thing that amazes me about languages like Lisp & Prolog is the possibilities to treat the program as DATA i.e. to be able to change the CODE on the fly ? Or the Perl language is diifferent in this aspect and such thing is not feasable/worth ? Probably the reason that Perl6 parser will be in Perl will give us some freedom on this issue... Re:more questions
Elian on 2002-05-22T03:29:10
To freeze and thaw properly requires core support, otherwise it just can't be done without a lot of really evil, and fragile, hackery. Perl 5 doesn't quite do it completely. Perl 6 will.Does it really matter? (the functionality will be available, it only makes sense to put it in a module -- i'm pretty sure that's where it will end up, who wants a bloated perl)it was mentioned that Parrot will allow freezing/thawing stuff ? will there be keywords for this or it will be separate modules like it is today with Perl5 ?He's talking about the lower level representation. In Lisp you can get at and manipulate the compiled representation of the program--equivalent to messing with perl 5's optree. Yes, we'll be able to do it, and it'll be as straightforward as anything at that level can be. Better than what you can do with the B:: modules and perl 5, certainly.I'm not familiar with List or Prolog. What exactly do you mean? In Perl6 the entire program will be available to itself ( the program ). Every { BLOCK } will be turned into a closure, and every pod BLOCK into a stream. You can manipulate each as you see fit. Also, eval will still exists... does that clear it up for you?One last thing may be not in the context of all this i was wondering... one thing that amazes me about languages like Lisp & Prolog is the possibilities to treat the program as DATA i.e. to be able to change the CODE on the fly ? Or the Perl language is diifferent in this aspect and such thing is not feasable/worth ? Probably the reason that Perl6 parser will be in Perl will give us some freedom on this issue...
Having asked the question, I have some comments on the response:
- Throw out the prototype...
This is more of a "how to do it" than "this is the goal", but I recognize the underlying intent is to take 100% backwards compatibility off the table as a requirement.
- Recognize that we cannot design a perfect language.
A bit of a meta-goal, I think. Once we recognize that we cannot design a perfect language, what are the resulting implications? Yes, the intent is to make Perl's grammar mutable, but to what extent (for example, do we want to add more direct support within the language for recursive descent parsing?) and what cost?
- Evolve Perl's evolvability.
What specific language constructs are intended to support Perl's evolvability? For example, one of Stroustrup's design goals for C++ to support evolvability was to allow new capabilities to be added via libraries. Perl modules are here and work great; what's next?
(I like using Stroustrup's design guideline of extensibility through libraries as an example, because a lot of C++'s design draws directly from this principle, with direct implications on how C++ has grown and spread across the programming community.)
- Optimize Perl's complexity.
Unification of syntax is a definite plus.
- Recalculate the Huffman coding.
While in principle this is a good idea, I have some concerns about going overboard on measuring Huffman coding by keystrokes instead of concepts. The bigger hurdle in understanding code is not the number of characters in the code, but the number of concepts that need to be understood. I would be happy to type more and use fewer concepts. (Not that new concepts are bad; I just believe that we need to be careful not to overwhelm the programmer.)
- Stay natural.
Perl's DWIM nature is a double-edged sword: yes, if you know the innards of Perl very well, it often does what you mean, but sometimes it doesn't, especially if your mind doesn't happen to be in tune with Larry's... The basic problem remains that computers to-date still need quite precise instructions on how to handle things. Perl tries to hide this by having a whole framework of rules to automagically produce the right result; when it works, it works great, but when it doesn't, it can fail spectacularly.
I would personally like to see the following issues addressed:
Making Perl easier for beginners to learn. The very nature of how the Perl 6 redesign is being done has resulted in a lot of internal discussion among experts, which I think may have had some negative effects. (For example, for beginners, it is blindingly obvious that "." is better than "->" for method access.) Naturally, this shouldn't be the only criterion for judging changes (e.g. regular expressions are always going to be hard for beginners, so I wouldn't go overboard in trying to simplify them for newbies), but I think it deserves consideration.
While on the topic of regular expressions and new Perl users, if regular expressions are redone along the lines of the recently dropped hints, Unix users thinking of learning Perl will be discouraged from doing so, as they will be unable to reuse their knowledge from the legacy Unix tool set. I hope that some kind of compatibility mode might be retained, to help jumpstart new users from the Unix world. (DOS/Windows users, who usually don't have much previous experience with regular expressions, would probably not find the new syntax as jarring.)
I originally had some other points to raise, but I need to mull over the consequences of the proposed module versioning mechanisms, which I had not seen before.