I just debugged a problem which proved to be that "and" evaluated both arguments before checking whether either was false. That's fine, not all languages handle x = (will_return_true() || loop_forever()) ? "win" : "lose" in short circuit fashion.

Is there prior art on a symmetric equivalent?

Interpret x = (loop_forever() || will_return_true()) ? "win" : "lose" as successfully as the conventional way around.

Short circuit evaluation on and, or is essentially control flow wrapped in syntax. The control flow I'm looking for would amount to:

  1. Start evaluating both arguments
  2. When either completes, see if the other is still necessary
  3. Kill off the other and return immediately when possible

Also of interest would be any language which takes this approach to argument evaluation without the above syntax. I'm tagging as functional-programming because the above wouldn't play nicely with side effects, especially if it's non-deterministic which branch completes first.

I don't think this is equivalent to prolog style back tracking but could probably be persuaded otherwise.

  • 4
    Prior art? Are you trying to patent something? – user22815 Sep 13 '17 at 0:24
  • 2
    Yes, prior art would be two threads and a join(), or two Futures and a join(), or something based on streams and select(). – 9000 Sep 13 '17 at 0:35
  • I don't know about "prior art", but wouldn't think the situation you describe requires much art to begin with. Fot your particular example, I'd "short circuit" it by explicitly writing x=(loop_forever()?"win":(will_return_true()?"win":"lose")); regardless of the language's semantics for that syntax. And, of course, I put the easier-to-evaluate function first, which the language might not be able to reliably do in any case. – John Forkosh Sep 13 '17 at 1:45
  • 1
    Pretty sure I saw something like this in Haskell's parallel library. – user253751 Sep 13 '17 at 3:12
  • @Snowman No patent aspirations, trying to assess whether the utility justifies the implementation. – Jon Chesterfield Sep 13 '17 at 7:15

Yes, something somewhere probably has done this, but... why? I mean, how often do you have two or more predicates that

1) take a long enough time that you want to run them in parallel, and the overhead is worth it


2) can be interrupted promptly enough to make it worth stopping them early


3) don't care which side effects are run, if any.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.