On Sat, Feb 12, 2005 at 12:19:46PM -0600, Rod Adams wrote:
> I reread S09, and I believe "autothreading" is the wrong term for the
> iteration that a junction incurs (Even though it appears in the section
> immediately after Junctions. Autothreading is something far weirder,
> dealing with partial dimensional slices, I believe. And in that case, it
> makes sense to turn off autothreading for slurpys, since in flattening,
> you get rid of the messy dimensions. Therefore I suspect that the above
> is wrong, and the behavior of C<say 'cat'|'dog'> is still to duplicate.
The first large paragraph in the section on Junctions says:
Some contexts, such as boolean contexts, have special rules for
dealing with junctions. In any scalar context not expecting a
junction of values, a junction produces automatic
parallelization of the algorithm. In particular, if a junction
is used as an argument to any routine (operator, closure,
method, etc.), and the scalar parameter you are attempting to
bind the argument to is inconsistent with the Junction type,
that routine is "autothreaded", meaning the routine will be
called automatically as many times as necessary to process the
individual scalar elements of the junction in parallel.
That last sentence says that autothreading is exactly this implicit
multiple call behavior that worries you.
Let's set aside for the moment the fact that slurpy arrays/hashes
aren't autothreaded and talk about a user-defined routine:
sub foo ($alpha) { ... }
It doesn't take much imagination to come up with a mechanism for Perl6
programmers to stop the autothreading:
sub foo is nonthreaded ($alpha) { ... }
which would cause an execption of some sort on attempted
"junctification"
The down side is that programmers need to be more aware of
subroutine/method side effects and write their programs accordingly.
Because of this, I'd suggest that autothreading of user-defined routines
not be the default, but rather enabled via a pragma of some sort (or, of
course, via an "autothreaded" trait). For the built-in routines this
isn't a worry as we get to design them appropriately.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
