"?:", "a and b or c" or "iif"

[Michael Hudson]

Michael Vanier <mvanier at bbb.caltech.edu> writes:

> > Michael Vanier writes:
> >  > This sounds like another job for bytecodehacks :-)  

Enough hints ;-)

This should work:

from bytecodehacks.code_editor import Function
from bytecodehacks.ops import *
from bytecodehacks.find_function_call import find_function_call

def iifize(func):
    func = Function(func)
    cs = func.func_code.co_code

    while 1:
        stack = find_function_call(func,"iif")

        if stack is None:
            break

        load, test, consequent, alternative, call = stack

        cs.remove(load)

        jump1 = JUMP_IF_FALSE()
        cs.insert(cs.index(test)+1,jump1)

        jump2 = JUMP_FORWARD()
        cs.insert(cs.index(consequent)+1,jump2)
        
        jump1.label.op = alternative
        jump2.label.op = call

        cs.remove(call)

    cs = None
    
    return func.make_function()

This was written in not-very-long-at-all, so take with a pinch of salt
please. 

Also it's written to use my local copy of bytecodehacks, which has
been modified in various subtle ways, but that shouldn't matter.

I'd release a new version of bytecodehacks, but

a) My exams start in a week 
b) The various subtle changes mean sundry bits may be confusingly
   broken
c) My exams start in a week
d) The docs have gotten out of date.
e) My exams start in a week
f) There are some memory leaks (cursed cyclic references!)
g) My exams start in a week

You get the idea...

> A couple of points:
> 
> 1) I would hope that the compiler could recognize the (usual) case where
>    none of the arguments are lazily evaluated and generate code that's as
>    good as the current python implementation.

That'd be difficult, as the Python compiler has no idea which function
will actually be called at a given call site (for all it knows someone
might come along and inflict a bytecodehack on it...)
 
> 2) It is true that it isn't evident from the calling side which arguments
>    are lazy and which aren't.  I don't see why this is such a problem;
>    could you give an example?  I hate to keep pointing at scheme and lisp,
>    but the same argument is levelled against macros in those languages, and
>    somehow their users manage to cope.  Even in current python, we don't
>    know if an argument is supposed to be an integer or a string, but we
>    manage :-)  It is true, though, that having lazy arguments is getting
>    very close to having macros (without changing the syntax; thus it's very
>    close to what bytecodehacks is doing, although not as general).
> 
> I think the larger issue is this: we don't want to saddle python with a lot
> of ad-hoc additions to solve minor issues (like ?:,
> assignment-in-expressions, etc. etc.) because that makes the language lose
> its simplicity that we all like.  Therefore, I think it's best to look for
> higher level meta-mechanisms that can provide a whole bunch of different
> features that otherwise would require a lot of individual changes.  Of
> course, the more powerful the feature, the more prone it is to abuse, so
> there's a lot to think about.  But I prefer a few really powerful features
> to a lot of not-so-powerful features.  That's a matter of taste, of course.

Well, of course, given lambda, set! and macros you can basically cook
up scheme...

Yours,
Michael