Also, the Perl 6 one-liner is sort of laughably cute . I'm not sure I believe it would actually work
I don't think any current implementation supports auto-parallelization of hyperops. Regardless, hyper is really only spec'd to remove the result-ordering requirements so that it may optimize it (I wouldn't be surprised if was executed in chunks in slightly more sophisticated implementations.)
From my reading of the docs, it (>>.) doesn't seem to require parallelization in the implementation, at all...it just allows it and requires code to be parallel safe, but doesn't impose any parallel requirements on the Perl 6 implementation. So, something like that Perl one-liner that would require parallelism to even work at all simply isn't valid. It might be possible to build a Perl 6 that would exhibit the right behavior, but it would be unspecified behavior.
So, I think that tiny little implementation is bunk. I'd be curious to see what the actual smallest Perl 6 implementation would look like, or if it would be the smallest Perl 5 version except using "say" to shave off two characters.
(>>.) doesn't seem to require parallelization in the implementation, at all...it just allows it and requires code to be parallel safe
That's pretty much what I said.
I'd be curious to see what the actual smallest Perl 6 implementation would look like
If you want to guarantee it will work, then it will be about as long as a Perl 5 version. Every brief way to parallelize leaves a lot of the semantics up to the implementation. There's a good reason for that: this is a concurrent problem, but the hyperops are meant for parallelizable problems.
Yeah, I know, I was just working through it in my own head. Seeing it in the context of this "solution" to the sleep sort problem caused me to think hyper-ops were something they are not. So, I did a bunch of reading to figure out what they actually are. It took a while to wrap my head around it.
The side benefit is that it caused me to download a Perl 6 implementation for the first time since pugs many years ago. I probably won't be using it for anything other than tinkering, of course, but nothing wrong with playing with new things. And, YAPC is coming up, so I can hang out with the cool kids who are talking about Perl 6 and Rakudo.
Perl 6 has been making strides lately. There's a bit of a refactor in the wings which should make it much more processor and memory efficient.
If it had the performance (and a package in Debian sources), I would be using it in production right now. Between grammars and the (clean!) syntax support for high order programming, it solves a lot of my headaches.
Oh hey, apparently the order of the results is maintained, according to Larry Wall. I'm not sure if that's new, or I misread something. (I was sure I read something about the result order being undefined.) So the tiny Perl 6 version does nothing at all for sorting per spec.
I don't think any current implementation supports auto-parallelization of hyperops. Regardless, hyper is really only spec'd to remove the result-ordering requirements so that it may optimize it (I wouldn't be surprised if was executed in chunks in slightly more sophisticated implementations.)