Author |
Topic: about GOSUBs (Read 1504 times) |
|
BrianM
New Member
member is offline
Posts: 15
|
 |
Re: about GOSUBs
« Reply #15 on: Aug 2nd, 2016, 8:19pm » |
|
Richard
I often use underscores in other languages and so I used them in LB labels without thinking whether they were allowed or not and as they worked I never checked. So my mistake.
The LB documentation is often at odds with what is actually implemented. The help talks about alphanumeric labels (those in square brackets) and then goes on to say spaces and numbers are not allowed, in which case they are not alphanumeric. The basic code for freeform uses . and digits in labels.
A quick check has shown that the characters _.%&\?{}!# can also be used in labels and there could be others.
I think your approach of using the same syntax for labels and variables is probably the most sensible one.
But to get back to my original point. Despite many people declaring that gosubs are obsolete, they still have their uses.
Brian Matthews
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: about GOSUBs
« Reply #16 on: Aug 2nd, 2016, 8:37pm » |
|
on Aug 2nd, 2016, 8:19pm, BrianM wrote:| The LB documentation is often at odds with what is actually implemented. |
|
You're telling me: having to discover largely by trial-and-error what LB does and doesn't do, rather than being able to rely on the documentation, is one of the main reasons why it took so long to get LBB to the degree of compatibility it currently has.
Quote:| Despite many people declaring that gosubs are obsolete, they still have their uses. |
|
I strongly disagree. I haven't used a GOSUB in a program for around 35 years, and I've not missed them.
Richard.
|
|
Logged
|
|
|
|
BrianM
New Member
member is offline
Posts: 15
|
|
Re: about GOSUBs
« Reply #17 on: Aug 2nd, 2016, 9:21pm » |
|
Richard
I would hazard a guess that your Basic programming has largely been with BBC Basic which uses dynamic scoping for variables so that a called FN or PROC sees the same variables as the calling FN or PROC (or main) unless local variables or parameters are used. This makes data sharing between FNs and PROCs easy and without the need for special GLOBAL variables or passing large amounts of data via parameters. What I am suggesting is this can be emulated in LB and LBB which use static variable scoping by using GOSUBS inside SUBS and FUNCTIONS. In some cases this can reduce the complexity of the code structure. I do not advocate general use of GOSUBS
Brian Matthews
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: about GOSUBs
« Reply #18 on: Aug 2nd, 2016, 10:13pm » |
|
on Aug 2nd, 2016, 9:21pm, BrianM wrote:| I would hazard a guess that your Basic programming has largely been with BBC Basic which uses dynamic scoping for variables so that a called FN or PROC sees the same variables as the calling FN or PROC |
|
Sadly yes. I work around that shortcoming in two ways: firstly those variables that I really want to be GLOBAL get commented as such at the start of the program, so that at least it's clear to the reader even though it's not enforced by the language. Secondly I use strict naming conventions (local variable names consisting of only lowercase letters whilst globals use mixed case); the Cross Reference utility will then warn me if I inadvertently access a variable which is neither local nor global.
Whilst neither of those strategies compensates for the weak scoping of the language they are better than nothing.
Quote:| This makes data sharing between FNs and PROCs easy and without the need for special GLOBAL variables or passing large amounts of data via parameters. What I am suggesting is this can be emulated in LB and LBB |
|
True, but why would you want to emulate a weakness of a language? One can justify static (lexical) scoping rules that allow an inner block to see the variables declared in an outer block, but not dynamic scoping that allows the same thing to happen at run time even if the functions are physically separated in the code.
I would always explicitly pass as parameters variables that need to be accessed by a sub-function, even if the dynamic scoping allows it to see those same variables.
Richard.
|
|
Logged
|
|
|
|
BrianM
New Member
member is offline
Posts: 15
|
|
Re: about GOSUBs
« Reply #19 on: Aug 3rd, 2016, 12:53pm » |
|
Richard
I agree totally with your last post.
The dynamic scoping of BBC Basic can cause problems by forgetting to declare a variable as local and inadvertently updating the variable with the same name in the calling PROC or FN. I presume this is the weakness you are referring to.
I am not trying to emulate dynamic scoping but rather the file scoping of the C programming language. LB and LBB only provide global or local variables. What I would like is something in between.
If a large sub or function is refactored into a number of smaller subs and functions then the problem of data sharing arises. As you say this can be achieved by the use of globals (suitably named) or by passing parameters. I prefer the passing of parameters but this does not look right when the same parameter list is used over and over again and with parameters passed BYREF. This cries out for C file scoping or perhaps using OOP classes and class properties. In these instances I consider using gosubs but I realise I am not going to pursuade you that it might be a good idea. To my mind gosubs within subs and functions do give :-
Quote:| scoping rules that allow an inner block to see the variables declared in an outer block |
|
Perhaps I should forget LB compatibility and investigate the OOP extensions of LBB.
Brian Matthews
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: about GOSUBs
« Reply #20 on: Aug 3rd, 2016, 10:04pm » |
|
on Aug 3rd, 2016, 12:53pm, BrianM wrote:| I prefer the passing of parameters but this does not look right when the same parameter list is used over and over again and with parameters passed BYREF. |
|
The technique I usually adopt in BBC BASIC is to store the 'shared variables' in a structure. That structure can be made LOCAL (or PRIVATE) to the enclosing function, and can be conveniently passed - as a single parameter - to all those sub-functions that need to share its contents. This seems to be the best of both worlds: no need for the sub-functions to implicitly share variables through lexical scoping, but equally no need to pass multiple parameters by reference each time.
Of course this solution doesn't help in Liberty BASIC, because structures are always global. This is mindbogglingly stupid (almost as stupid as arrays being always global) - are you listening Mr Gundel? 
Quote:| Perhaps I should forget LB compatibility and investigate the OOP extensions of LBB. |
|
As has been discussed here before, it is reasonable to utilise the OOP features of LBB not because you actually want to write 'Object Oriented' code as such, but simply as a workaround for the absence of local arrays and structures.
Richard.
|
|
Logged
|
|
|
|
|
