Lexical and dynamic scoping are both useful, but they serve different (indeed, totally unrelated) purposes. Lexical scoping is for avoiding namespace collisions. Package scope in general serves this purpose also, at a different level. Dynamic scope is not useful for avoiding namespace collisions, but it has other uses, things lexical and package scope do not do (directly as such). Dynamic scope allows for control-flow-based values, so that a variable can temporarily hold a new value for a while, and then revert to the old one.
It is possible to get around a lack of dynamic scope by passing lots and lots of parameters in every single function call, but in many cases that's cumbersome and inefficient. (I don't mean inefficient with computer resources; the compiler can probably optimise a lot of it away, and anyway dynamic scope uses some resources too; I mean inefficient with programmer time.) It's also possible to get around it with closures or object structures, but sometimes dynamic scoping is the most straightforward way to do it.
I was not aware of any serious computer scientist thinking that implementing dynamic scoping was a mistake; there are certainly plenty who think _not_ implementing lexical scoping is a mistake, but that's an entirely separate issue. Neither type of scoping is substitutable for the other; they do very different things.Assembly language programmers have been using both kinds of scope since the beginning of time; lexical scope is when you store a value at a certain memory address and only use it in one little segment of your program. Dynamic scope is when you push the value from a certain memory address onto the stack, do some stuff, then pop it back off into the same place it came from. It is highly impractical (some would say impossible) to write a program of any substantial complexity without in some fashion or another doing both of these things. It's just a question of whether the language and/or the programming environment provides a direct mechanism or whether the programmer has to make special arrangements. (I already listed some ways to work around a lack of dynamic scoping. You can also work around a lack of lexical scoping, by giving your variables unique names. A lack of package scope is more of a pain, but this can be worked around too, by simply including the name of the package at the start of the name of every variable. This makes for verbosity, but it works in a pinch.)
Anyway, Perl6 is going to have dynamic scope one way or the other (though the misleading keyword "local" is being changed to "temp", which makes sense); all I'm thinking to implement is buffer scope (which would be used for the same sorts of things as dynamic scope, albeit in different situations, much as package scope and "my" lexical scope are used for the same thing in different situations). Perl6 also introduces something called hypothetical scope, which adds yet another semantic; it is not equivalent to either lexical or dynamic scope, but is its own thing, or perhaps a sort of hybrid.
for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
In reply to Re: Implementing (elisp-like) buffers in Perl 6: how to do buffer-localisation of arbitrary package variables?
by jonadab
in thread Implementing (elisp-like) buffers in Perl 6: how to do buffer-localisation of arbitrary package variables?
by jonadab
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |