Author: lwall Date: 2009-04-06 18:41:16 +0200 (Mon, 06 Apr 2009) New Revision: 26100
Modified: docs/Perl6/Spec/S09-data.pod Log: Be explicit about design uncertainty wrt semantics of junctional collapse. Modified: docs/Perl6/Spec/S09-data.pod =================================================================== --- docs/Perl6/Spec/S09-data.pod 2009-04-06 09:40:39 UTC (rev 26099) +++ docs/Perl6/Spec/S09-data.pod 2009-04-06 16:41:16 UTC (rev 26100) @@ -12,9 +12,9 @@ Maintainer: Larry Wall <la...@wall.org> Date: 13 Sep 2004 - Last Modified: 18 Mar 2009 + Last Modified: 6 Apr 2009 Number: 9 - Version: 31 + Version: 32 =head1 Overview @@ -1041,6 +1041,23 @@ in fact scalar parameters, though, so you could pass a junction of array or hash objects.) +The exact semantics of autothreading with respect to control structures +are subject to change over time; it is therefore erroneous to pass +junctions to any control construct that is not implemented via as a +normal single or multi dispatch. In particular, threading junctions +through conditionals correctly could involve continuations, which +are almost but not quite mandated in Perl 6.0.0. Alternately, we +may decide that boolean contexts always collapse the junction by +default, and the exact value that allowed the collapse to "true" +is not available. A variant of that is to say that if you want +autothreading of a control construct, you must assign or bind to +a non-C<Object> container before the control construct, and that +assignment or binding to any such container results in autothreading +the rest of the dynamic scope. (The performance ramifications of this +are not clear without further experimentation, however.) So for now, +please limit use of junctions to situations where the eventual binding +to a scalar formal parameter is clear. + =head1 Parallelized parameters and autothreading Within the scope of a C<use autoindex> pragma (or equivalent, such as
