Shortcut semantics for boolean operators at compile time

Bug #603951 reported by Eike on 2010-07-10
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

Currently both arguments of the boolean operators "and" and "or" are evaluated at compile time. impement short cut semantics because everybody expects this.

Possible solutions:
 - Follow Python's implementation closely:
    - At compile time call `argument.__bool__()` and decide in special purpose code.
    - For generated code use special function which is converted by code generator back into shortcut
      operator. (Similar to current implementation.)

 - Implement idea from Greg Ewing (PEP 335:
        - Special methods for boolean operators `and`, `or`.
          To retain the shortcut semantics split the execution of the
          operator into two phases:
              - first call `__and1__(self)`, `__or1__(self)` if these operators
                can compute the result they return `True`/`False`; otherwise they
                return the special value !NeedOtherOperand.
              - if !NeedOtherOperand was returned call:
                `__and2__(self, other)`, `__rand2__(self, other)`
                return the special value `NeedOtherOperand`.
              - if `NeedOtherOperand` was returned call:
                `__and2__(self, other)`, `__rand2__(self, other)`
              - Calls with unknown arguments always end up as: `__xx2__`
                (this is implemented)

Eike (eike-welk) on 2010-07-10
Changed in freeode:
importance: Undecided → Wishlist
Eike (eike-welk) on 2010-07-10
tags: added: interpreter
Eike (eike-welk) on 2011-06-10
description: updated
Eike (eike-welk) on 2012-02-29
description: updated
Eike (eike-welk) on 2012-02-29
Changed in freeode:
milestone: none → 0.4.2
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers