sfk@otter.hpl.hp.com (Steve Knight) writes:
> If we neglect shadowing, then when we
>ask for the value of a variable inside a break loop we get the same
>value both with lexical and dynamic binding. The only issue is that
>getting access to variables in the fashion is easier to implement with
>dynamic binding.
Procedure A, with local variable LA, invokes B, with local variable LB.
An error occurs inside B. We are now in a break loop. In what environment
are we working? With lexical scope I can see three possible answers:
1. We're in a brand new environment, with no local variables at all.
To get to LB you have to say "back up a frame on the stack"; to get to
LA you have to say it twice.
2. We're in B's environment. Now LB is available in the ordinary way,
but LA still isn't.
3. Break loops have different scope rules from those of the normal
language; LA and LB are both available using the usual notation for
variables and without any extra commands to switch frames. In effect,
break loops obey dynamic scope.
All three of these are unacceptable. Instead, the right answer is
4. The language obeys dynamic scope in the first place, so LA and LB
are naturally both available in any environment that's created while
B is running.
>It doesn't matter whether its a list of symbols or a procedure the key
>difference is notational convenience. The obvious comparison is
>with Smalltalk which uses [ ... ] to denote a nullary procedure with
>lexical binding. In Smalltalk the control contructs are indeed
>implemented in the suggested way.
No, I think the key difference is about metaphors. When you create
a list, you don't want to be thinking about procedures, in my view.
But you *do* want to be able to run the list, if it happens to look
like something runnable.
|