[Python-ideas] Jump to function as an an alternative to call function

[Steven D'Aprano]

On Wed, Aug 15, 2018 at 09:58:28PM -0400, David Mertz wrote:
> When did you last read the Dijkstra paper. It's short and he explains very
> well why exactly all the constructs you mention are unlike Goto.

Of course I've read it, and no he does not. He only mentions if...else 
and looping. He doesn't mention break, continue, exceptions (I don't 
think exceptions had even been invented in 1968).

I think that if Dijkstra were still alive, he would probably chose to 
understate or dismiss the similarities between goto and break/continue. 
Others might choose to focus on the similarities rather than the 
differences, e.g. "continue" is just a goto to the start of the loop, 
"break" is goto the end of the loop.

But this isn't a debate over the pros and cons of goto. Goto is not 
relevant. This proposal is for dynamic scoping, not a way to change 
execution order or jump from one part of code to another.


> This isn't a proposal to subroutines, it's a proposal for subroutines in
> which all lexically scoped variables are implicitly nonlocal.

Language fail :-)

"This isn't a proposal for subroutines, it's a proposal for subroutines" 
:-)

I've read the proposal differently, for dynamic scoping, not lexical 
scoping plus implicit nonlocal. It may be that you could get similar 
results from either, but they are fundamentally different.

Python already has a kind of dynamic "scoping" (of sorts) which you 
probably use every day and never think twice about it. When an exception 
occurs, the scope of the exception handlers is the runtime call stack, 
not the lexical scope.

There's nothing *inherently* bad about dynamic resolution of FOO, for 
any value of FOO (be it inheritence and method resolution, attribute 
lookup, scoping, or exception handling). It has its pros and cons, of 
course. I'd even allow that if overused or misused, dynamic scoping will 
be hard to reason about.

(I believe it was Guy Steele who proved that dynamic scoping is 
equivalent to a single global scope, but of course that only applies 
when *all* functions are *always* dynamically scoped.)

Just as we allow global variables for those odd cases where they are 
needed (or even just because it is more convienent), so there's a case 
for allowing dynamic scoping. Especially when the alternatives (classes, 
closures) are clumsy, difficult to get right, full of duplicated code 
and boilerplate.

I wouldn't want every function call to use dynamic scoping, but there 
are times where I have really wanted to access the caller's environment, 
not the environment where my function was defined.

We ought to give this concept a fair shake, not just dismiss it on the 
basis of platitudes "X considered harmful", especially when X isn't even 
relevant.


> That's basically Goto

Its nothing like goto, except to the (small) degree that any jump to a 
subroutine is a goto.


> certainly course enough to suffer all of Dijkstra's
> complaints.
> 
> Yes, technically this could be called dynamic scope instead. But
> notwithstanding the use in elisp, that's pretty widely regarded as a bad
> ideas (even by the emacs developers who regret that early decision).

Richard Stallman doesn't.

I'm sure you can still find thousands of Python developers who regret 
that it uses significant whitespace and no braces. I know you can find 
Python developers who hate "lambda", and I know some who don't 
understand comprehensions and regret their inclusion in the language.

Just about every proposal for new syntax is objected to, sometimes 
vehemently enough to drive Guido into "permanent vacation" (retirement) 
from his position of BDFL :-(

So yes, I'm sure that some Emacs developers think dynamic scoping is a 
mistake, just as some Python developers think FOO is a mistake, for just 
about any value of FOO you can think of.


-- 
Steve