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."