Re: Tweaking junctions
Martin D Kealey asked: Or do we not invert junctions, and run the risk of unexpected action-at-a-distance instead? I think our current approach is correct. That is: we invert junctions on operators that are themselves intrinsically inverted (such as !=, !~~, !), but do not invert on those that are not (such as ==, ~~, =). Or rather, we *never* invert junctions at all, but merely honour the standard semantics of the prefix:! metaoperator: hoisting the negation outside the entire operation and applying it once the underlying operation is complete. The apparent paradox you demonstrated with the two interpretations of C$foo ($bar | $zot) is due to the assumption (employed in the second interpretation) that is identical to !=. Certainly that is true for simple scalar numbers, but not always for vector types such as tuples, sets, bags, complex numbers...or junctions. That doesn't make either or != intrinsically invalid on vector types (though they obviously are inappropriate for *some* vector types); it just means you can't reasonably treat the two operators as universally interchangeable, just because they sometimes are. In summary, the problem here seems to be that, algebraically, junctions don't behave exactly like non-junctions. Which is true, but no more a problem than the fact that, algebraically, complex numbers don't behave exactly like non-complex numbers, or that sets don't behave exactly like non-sets, or that Rats don't behave exactly like Nums, which don't behave exactly like Ints, which don't behave exactly like ints either. And, of course, that's why Perl 6 has strong typing. So that, when these differences in behaviour do matter, we can specify what kind(s) of data we want to allow in particular variables, parameters or return slots...and thereby prevent unexpected kinds of data from sneaking in and violating (un)reasonable expectations or inducing (apparent) paradoxes. :-) With regard to your other point: If it's about parallel data handling, then we have to be prepared to (notionally) fork the entire rest of the runtime, even as far as having a definition of what return value the parent process sees (from exit) when those threads are implicitly collapsed at termination. That's certainly true, although junctions are supposed to guarantee to coalesce all the threads they may generate back into a single superimposed result back in the originating thread. The problem only arises if an operation or subroutine that has been junctively threaded terminates without returning. But that's just having a side-effect, which we already know is inappropriate for junctions (and hyperoperators, and autothreaded loops, and pretty much any other kind of parallel construct). Damian
Re: Tweaking junctions
Damian Conway wrote: If it's about parallel data handling, then we have to be prepared to (notionally) fork the entire rest of the runtime, even as far as having a definition of what return value the parent process sees (from exit) when those threads are implicitly collapsed at termination. That's certainly true, although junctions are supposed to guarantee to coalesce all the threads they may generate back into a single superimposed result back in the originating thread. The problem only arises if an operation or subroutine that has been junctively threaded terminates without returning. But that's just having a side-effect, which we already know is inappropriate for junctions (and hyperoperators, and autothreaded loops, and pretty much any other kind of parallel construct). Could thread termination without a return reasonably be treated as another way of saying returns nothing or alternately returns an empty junction (a junction ranging over zero values)? Or would that instead better be treated as an error such that returning nothing should have been done explicitly? -- Darren Duncan
Announce: Rakudo Star 2010.10 released
On behalf of the Rakudo and Perl 6 development teams, I'm happy to announce the October 2010 release of Rakudo Star, a useful and usable distribution of Perl 6. The tarball for the October 2010 release is available from http://github.com/rakudo/star/downloads. Rakudo Star is aimed at early adopters of Perl 6. We know that it still has some bugs, it is far slower than it ought to be, and there are some advanced pieces of the Perl 6 language specification that aren't implemented yet. But Rakudo Perl 6 in its current form is also proving to be viable (and fun) for developing applications and exploring a great new language. These Star releases are intended to make Perl 6 more widely available to programmers, grow the Perl 6 codebase, and gain additional end-user feedback about the Perl 6 language and Rakudo's implementation of it. In the Perl 6 world, we make a distinction between the language (Perl 6) and specific implementations of the language such as Rakudo Perl. The October 2010 Star release includes release #34 of the Rakudo Perl 6 compiler [1], version 2.9.0 of the Parrot Virtual Machine [2], and various modules, documentation, and other resources collected from the Perl 6 community. This release of Rakudo Star adds the following features over the previous Star release: * A simple implementation of 'require' * Local timezone is available in $*TZ * Implementations of ms// ss/// (samespace) * Speed improvements to Str.flip * Hyperoperator versions of += * Improved diagnostic messages and warning messages * True and False now stringify properly * Attribute modification via introspection There are some key features of Perl 6 that Rakudo Star does not yet handle appropriately, although they will appear in upcoming releases. Thus, we do not consider Rakudo Star to be a Perl 6.0.0 or 1.0 release. Some of the not-quite-there features include: * nested package definitions * binary objects, native types, pack and unpack * typed arrays * macros * state variables * threads and concurrency * Unicode strings at levels other than codepoints * pre and post constraints, and some other phasers * interactive readline that understands Unicode * backslash escapes in regex [...] character classes * non-blocking I/O * most of Synopsis 9 * perl6doc or pod manipulation tools In many places we've tried to make Rakudo smart enough to inform the programmer that a given feature isn't implemented, but there are many that we've missed. Bug reports about missing and broken features are welcomed at rakudo...@perl.org. See http://perl6.org/ for links to much more information about Perl 6, including documentation, example code, tutorials, reference materials, specification documents, and other supporting resources. An updated draft of a Perl 6 book is available as docs/UsingPerl6-draft.pdf in the release tarball. The development team thanks all of the contributors and sponsors for making Rakudo Star possible. If you would like to contribute, see http://rakudo.org/how-to-help, ask on the perl6-compi...@perl.org mailing list, or join us on IRC #perl6 on freenode. Rakudo Star releases are created on a monthly cycle or as needed in response to important bug fixes or improvements. The next planned release of Rakudo Star will be on November 23, 2010. [1] http://github.com/rakudo/rakudo [2] http://parrot.org/ [3] http://github.com/perl6/roast
