Re: Re: Implementing (elisp-like) buffers in Perl 6: how to do buffer-localisation of arbitrary package variables?

The purposes that they serve are not so different. In fact in many languages - including every version of Lisp before Scheme and Perl before my was introduced in Perl 5 - dynamic scope was routinely used for what we now tell people to use lexical scope for.

Admitted, there are differences. And there are times when you really do want dynamic scope. But those are few and far between. The times that I have used it are for locking logic (in which case straight dynamic scope does not do the job, I need the dynamic thing to be visible outside of my program) and once for a deep recursion test (you can use local on the values of a hash!). I could have survived without built-in dynamic scope for both cases, but would have had to use exception handlers to do it safely. (You need to catch every way of exiting the dynamic scope...)

As for the idea of having a ton of custom variables which can be accessed from anywhere that contains state, if your programs look like that then you probably could stand to learn something about good program design IMO. A multiplication of global or semi-global variables is a red flag for a bad design. (Geez, can I sound more arrogant?)

Comment on Re: Re: Implementing (elisp-like) buffers in Perl 6: how to do buffer-localisation of arbitrary package variables?

Replies are listed 'Best First'.

Re: Implementing (elisp-like) buffers in Perl 6: how to do buffer-localisation of arbitrary package variables?
by jonadab (Parson) on Apr 04, 2003 at 15:37 UTC

In fact in many languages - including every version of Lisp before Scheme and Perl before my was introduced in Perl 5 - dynamic scope was routinely used for what we now tell people to use lexical scope for.

That would be a grave mistake. If that is true, then I can certainly see why you would be hesitant about the use of dynamic scope; it is clearly inappropriate for avoiding namespace clashes. That wouldn't work very well at all; there would be all sorts of hard-to-debug problems if it were used for that. However, that doesn't mean dynamic scope isn't useful, or even that it's less useful than lexical scope; it only means it's not useful for the same kinds of things.

And there are times when you really do want dynamic scope. But those are few and far between.

I can't agree with that. When you understand dynamic scope properly (i.e., are using it for what it's good for, not as some kind of warped substitute for lexical scope), it's very useful indeed.

If you need to simulate lexical scope in a language that doesn't support it directly, the right way to do that is by naming convention (i.e., name your lexical variables starting with the name of the package (and possibly routine) that contains them), not by misusing dynamic scope. But it's also not appropriate to try to use lexical scope as a substitute for dynamic scope; that would be at least as hideously inappropriate, if it could even be made to work at all.

And no, most of the time you aren't going to be dynamically scoping lots and lots of variables. But the ones that you do need to scope that way, you need to scope that way. As you point out, trying to work around a lack of it is nightmarish. Yeah, it can be done -- in the same sense that recursion can be done in languages like line number BASIC that don't support passing parameters to subroutines. (I did this once. It was kinda fun, actually, in a perverse sort of way. I used a set of parallel arrays to simulate a stack, which I pushed my values onto before GOSUB (to save them) and then popped them off of after the routine RETURNed. It was messy, though, and fun only as an exercise, and I don't want to do it again.)

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$/}
[download]

[reply]
[d/l]


Problems? Is your data what you think it is?
	PerlMonks