Rod Adams <[EMAIL PROTECTED]> wrote:
> if $x == 3|4|5|6 {...}
>
> would thread over infix:<==> without any funkiness, since we'll assume
> operators are well written, and can take junctions as parameters, same as:
>
> if is_prime(3|4|5|6) {...}
>
> Would pass the junction to is_prime, to do with as it pleases, including
> throwing an exception. However,
>
> if is_prime(»3|4|5|6«) {...}
>
> would thread over is_prime, and collate the results outside of call.
So basically you're proposing that, rather than do one implicit loop
that'll probably do what you want, the default should be to do an
unknown number of implicit loops in somebody else's code, and you have
to ask explicitly for the more sensible behavior. Somehow this
doesn't strike me as an improvement.
> These semantics also give us the ability to easily mix and match what we send
> to a function, so we can say:
>
> if funky_test(all(@A), »any(@B)«) {...}
sub funky_test ( Junction|Any @a, @b ) { ... }
> Basically I'm putting all the power of threading into the hands of the caller.
The caller is not in a position to know if the callee is internally
structured in such a way that passing in a raw junction makes sense.
The right place to say "I can handle a junction, don't autothread" is
in the callee; that's the behavior @Larry is proposing.
> As for C< .. >, I'd say that it should handle junctions being fed into it by
> throwing an exception.
Why is this more sensible than returning a list of junctions in list
context and a junction of arrayrefs in scalar context? (I believe
infix:<..> will return an arrayref in scalar context, though I could
be wrong.)
(The array of junctions is negotiable, by the way; whatever it is,
though, it should probably be the same as the default meaning for list
returns from an autothreaded function.)
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
