>From a user's POV, I'm +1 on having overloadable boolean functions. In many cases I had to resort to overload add or neg instead of and & not, I foresee a lot of cases where the and overload could be used to join objects which represent constraints. Overloadable boolean operators could also be used to implement other types of logic (eg: fuzzy logic). Constraining them to just primitive binary operations in my view will be delimiting for a myriad of use cases.
<br><br>Sure, in some cases, one could overload the neg operator instead of the not but semantically they have different meanings.<br><br><div><span class="gmail_quote">On 5/25/07, <b class="gmail_sendername">Guido van Rossum
</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On 5/24/07, Greg Ewing <
<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br>> Guido van Rossum wrote:<br>><br>> > Last call for discussion! I'm tempted to reject this -- the ability to<br>> > generate optimized code based on the shortcut semantics of and/or is
<br>> > pretty important to me.<br>><br>> Please don't be hasty. I've had to think about this issue<br>> a bit.<br>><br>> The conclusion I've come to is that there may be a small loss<br>> in the theoretical amount of optimization opportunity available,
<br>> but not much. Furthermore, if you take into account some other<br>> improvements that can be made (which I'll explain below) the<br>> result is actually *better* than what 2.5 currently generates.<br>>
<br>> For example, Python 2.5 currently compiles<br>><br>> if a and b:<br>> <stats><br>><br>> into<br>><br>> <evaluate a><br>> JUMP_IF_FALSE L1<br>> POP_TOP
<br>> <evaluate b><br>> JUMP_IF_FALSE L1<br>> POP_TOP<br>> <stats><br>> JUMP_FORWARD L2<br>> L1:<br>> 15 POP_TOP<br>> L2:<br>><br>> Under my PEP, without any other changes, this would become
<br>><br>> <evaluate a><br>> LOGICAL_AND_1 L1<br>> <evaluate b><br>> LOGICAL_AND_2<br>> L1:<br>> JUMP_IF_FALSE L2<br>> POP_TOP<br>> <stats>
<br>> JUMP_FORWARD L3<br>> L2:<br>> 15 POP_TOP<br>> L3:<br>><br>> The fastest path through this involves executing one extra<br>> bytecode. However, since we're not using JUMP_IF_FALSE to
<br>> do the short-circuiting any more, there's no need for it<br>> to leave its operand on the stack. So let's redefine it and<br>> change its name to POP_JUMP_IF_FALSE. This allows us to<br>> get rid of all the POP_TOPs, plus the jump at the end of
<br>> the statement body. Now we have<br>><br>> <evaluate a><br>> LOGICAL_AND_1 L1<br>> <evaluate b><br>> LOGICAL_AND_2<br>> L1:<br>> POP_JUMP_IF_FALSE L2<br>
> <stats><br>> L2:<br>><br>> The fastest path through this executes one *less* bytecode<br>> than in the current 2.5-generated code. Also, any path that<br>> ends up executing the body benefits from the lack of a
<br>> jump at the end.<br>><br>> The same benefits also result when the boolean expression is<br>> more complex, e.g.<br>><br>> if a or b and c:<br>> <stats><br>><br>> becomes<br>>
<br>> <evaluate a><br>> LOGICAL_OR_1 L1<br>> <evaluate b><br>> LOGICAL_AND_1 L2<br>> <evaluate c><br>> LOGICAL_AND_2<br>> L2:<br>> LOGICAL_OR_2
<br>> L1:<br>> POP_JUMP_IF_FALSE L3<br>> <stats><br>> L3:<br>><br>> which contains 3 fewer instructions overall than the<br>> corresponding 2.5-generated code.<br>><br>> So I contend that optimization is not an argument for
<br>> rejecting this PEP, and may even be one for accepting<br>> it.<br><br>Do you have an implementation available to measure this? In most cases<br>the cost is not in the number of bytecode instructions executed but in
<br>the total amount of work. Two cheap bytecodes might well be cheaper<br>than one expensive one.<br><br>However, I'm happy to keep your PEP open until you have code that we<br>can measure. (However, adding additional optimizations elsewhere to
<br>make up for the loss wouldn't be fair -- we would have to compare with<br>a 2.5 or trunk (2.6) interpreter with the same additional<br>optimizations added.)<br><br>--<br>--Guido van Rossum (home page: <a href="http://www.python.org/~guido/">
http://www.python.org/~guido/</a>)<br>_______________________________________________<br>Python-3000 mailing list<br><a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br><a href="http://mail.python.org/mailman/listinfo/python-3000">
http://mail.python.org/mailman/listinfo/python-3000</a><br>Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com">http://mail.python.org/mailman/options/python-3000/nevillegrech%40gmail.com
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>Neville Grech