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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
