Forum Announcement
22/04/2018 - The Online Chat isn't working via the normal link.
You can connect via IRC, or using another web client - https://kiwiirc.com/client/chat.qlforum.co.uk/#qlforum

Odd behavour

Anything QL Software or Programming Related.
martyn_hill
Gold Card
Posts: 373
Joined: Sat Oct 25, 2014 9:53 am

Re: Odd behavour

Postby martyn_hill » Wed Feb 07, 2018 1:52 pm

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.


User avatar
tofro
QL Wafer Drive
Posts: 1339
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Odd behavour

Postby tofro » Wed Feb 07, 2018 2:23 pm

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


User avatar
pjw
Gold Card
Posts: 346
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Odd behavour

Postby pjw » Wed Feb 07, 2018 3:57 pm

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..


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
pjw
Gold Card
Posts: 346
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway

Re: Odd behavour

Postby pjw » Wed Feb 07, 2018 3:59 pm

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.


Per
For every complex problem there is an answer that is clear, simple, and wrong.
- H. L. Mencken
User avatar
Dave
SandySuperQDave
Posts: 1867
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Odd behavour

Postby Dave » Wed Feb 07, 2018 5:29 pm

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.



Return to “Software & Programming”

Who is online

Users browsing this forum: No registered users and 1 guest