The Sinclair QL Forum

Hi Pr0f (I finally get the spelling of your username right!)

Pr0f wrote:it does look messy - being able to amend a variable that's been declared as local, and being allowed to do so because you are being called by the procedure that declared it local. It's more regional then

Yes, depending upon the language (and its implementation) there are these two definitions of 'local' that have different 'lexical' scopes - namely:

a) Within only the most immediate definition where the LOCal is defined: referred to as 'static' scope - typically adopted in modern compiled languages, or else
b) Scoped within this definition AND all definitions called from here: referred to as 'dynamic' scope - which is how S*Basic applies the definition and which apparently takes much of its methodology from older languages such as Lisp.

I personally find S*Basic's dynamic scoping more helpful so as to reduce the amount of parameter passing (as a means of localising variables) needed. It does take some planning however to avoid tampering with similarly named variables within a chain of FNs/PROCs.

Modern languages like Pascal and even Java extend the (static, not dynamic) scope of LOCal variables into embedded objects and procedures. Nod so old-fashioned as you think, maybe

Tobias

martyn_hill wrote:I personally find S*Basic's dynamic scoping more helpful so as to reduce the amount of parameter passing (as a means of localising variables) needed. It does take some planning however to avoid tampering with similarly named variables within a chain of FNs/PROCs.

Great if you need to subdivide a larger program into functional units. Groups of procedures can then work with the same set of variables, local to the whole subset. Of course, individual procedures within the subset can still have variables local only to themselves. For S*BASIC, I wouldnt have it any other way But, as you say, some planning is needed..

Pr0f wrote:it does look messy - being able to amend a variable that's been declared as local, and being allowed to do so because you are being called by the procedure that declared it local. It's more regional then

A bit like cascading style sheets, perhaps? But thats not messy, its functionally astute, to my mind.

I think of it as local, or stackable local. Anything you can put on the stack below this point has access to this. Anything above this point doesn't.