Craig DeForest wrote:
Hmmm... It seems that this way does lie madness -- there's a fundamental ambiguity between autothreading happening inside or outside the declared loop, and there's no "least surprising" way to implement it. Certainly inside the loop is the easiest and most natural to implement, but that acts strange from an API standpoint. Outside the loop works well from an API standpoint but introduces all sorts of weird cases that the implementation has to consider.I would think that my latest idea of turning off "autothreading" per se, and replacing it with an explicit "threading" call/operator, would solve this dilemma. The idea was specifically to have it where threading happened on function calls when a junction was surrounded by hyper operators. Otherwise, the junction is passed "as is".
So we still get:
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.
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)«) {...}
Basically I'm putting all the power of threading into the hands of the caller.
I will further argue that C< »junction« > should not short circuit. It should do the simple brute force "try all values" approach, since the side effects are likely desired. Operators, which should be able to accept junctions as parameters, are encouraged to short circuit, since there are no side effects possible for the evaluation of that operator. By the time the operator gets called, it should have all the parameters it needs, and there are no more side effects to be had.
As for C< .. >, I'd say that it should handle junctions being fed into it by throwing an exception.
-- Rod Adams
