|Do you know where your variables are?|
First of all there's currently a Google Summer of Code project in the run that implements a simple to use NCI (native call interface), to make it easier to call C functions from parrot.
Secondly please remember that Perl 6 is designed for the utmost amount of flexibility, so it's very easy to have a nice syntax for new features, like natural arithmetic operators for vector and matrix operations.
Perl 6 comes with low-level data types (like int32 and uint32) and arrays with pre-defined shapes (see S09 for more details, there's also a section on PDL support. In conjunction with the optional static type declaration there's no reason why native Perl 6 number crunching should be any slower than C.
So to summarize, from the specification point of view the future looks very bright. But currently speed isn't the primary concern, so I don't expect the first versions of Perl 6 to be very fast.
But there's much more room for optimization for Perl 6 than for Perl 5 - on the language level as well as on the VM level (for one thing parrot does JIT already, perl 5 doesn't, and is not likely to do in near future).
A few more thoughts on concurrency: Perl 6 avoids some pitfalls that made concurrency rather hard in Perl 5, like the huge number of global variables. Stuff that was global in Perl 5 (like $_, $!, $1, $2, ...) is now mostly solved with contextual variables (lexically scoped variables that may change their value in an outer block), and the language design was done from ground off with concurrency in mind (or at least in the back of TimToady's mind).
Implementations are free (and encouraged) to autothread meta operators, so this:
is likely to happen in parallel without the programmer even noticing.
By the way complex numbers are natively supported in Perl 6.
So I think that both in terms of speed and syntax Perl 6 will be an improvement over Perl 5 (in the realm of sci. computing at least; don't want to start the overall discussion again), but it still needs much work to get there.
In reply to Re: What will scientific computing in Perl 6 look like?