[Python-3000] Switch and static, redux

[Guido van Rossum]

On 7/6/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
>
> > So, my proposal is to give up on static, accept PEP 3103 with the
> > following options:
> >   - Syntax alternative 2+B (unindented cases, 'case in ...' for multiple cases).
> >   - Semantics option 3 (def-time freezing)
>
> I agree with giving up on static, or at least treating
> it as a separate issue from switch.

OK, this much is a deal then.

> But there's one more thing I'd like to see discussed
> concerning def-time freezing:
>
>     apple = 1
>     banana = 2
>
>     def f():
>       ...
>       def g(fruit):
>         ...
>         switch fruit:
>           case apple:
>             ...
>           case banana:
>             ...
>
> With def-time freezing as currently proposed, this will
> evaluate the cases inside g() every time f() is called.
> But that would be wasteful, because they only depend on
> names defined at the module level.
>
> So I'd like to propose that "def time" be modified
> slightly to mean "def time of the outermost function
> that is still inside the scopes containing all the
> names that the case expressions depend on". Not
> sure about the wording of that, but I hope you get the
> idea. In the above example, that would be the def time
> of f(), rather than g().

I get the idea, and I don't like it. I thought of this case before and
decided that it really isn't worth the complexification (and I'm using
that word intentionally :-) of the rules. We don't have any rules like
that ATM, and it's not the kind of rule that is even close to anything
we do have (I claim that the def-time rule *is* close to something we
already have, i.e. parameter default values -- close, not the same,
mind you).

Somehow a switch doesn't really strike me as a typical idiom for
functional programming, so I doubt that the issue will matter in
practice; in order for this to make a difference you'd have to have an
inner function containing a switch *and* the inner function must only
be called once (or a small number of times) for each time it is
defined *and* the user must give a damn about optimization. The
combination of the first and second suggests a functional programming
mindset which somehow makes the third less likely.

Your suggestion also makes it hard to find a good place to store the
dispatch dict between the time the outer function is defined and the
time the the inner function is defined. We can't store it in the outer
function's local namespace (since it's not being called yet) so the
only place to store it would be the outer function object. But that is
not readily accessibly by the time the inner function object is being
defined (the outer function's name is not  a safe way to reference
it).

> I'd further suggest that a switch be allowed to reference
> names in the current scope, in which case no optimisation
> is done. That would take care of switches at the module
> level, without making the module level a special case
> with respect to the evaluation time rules.

More complexification that I don't like. The only idiom I'm
interesting in supporting is the one where the cases are constants
(even though the compiler may not know it if they are named
constants). Having a rule that prescribes optimization depending on
the scopes of variables involved in a set of expressions sounds like a
recipe for hard to debug bugs (since these rules are so subtle).

I might as well repeat a quote I heard recently (and had heard before)
from my good friend Brian Kernighan: "Debugging is twice as hard as
writing the code in the first place. Therefore, if you write the code
as cleverly as possible, you are, by definition, not smart enough to
debug it."

The changes to the rules that you are proposing make me think that we
are making the rules too "clever", which will making it that much
harder to debug issues around this. The much simpler rule that I
propose is simpler to debug because you don't have to know the scope
of the variables involved to know when the switch is frozen, which
means that you can't be misled by a variable whose scope you are
under- or over-estimating.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)