Gosub.02bas error

[AlyssonR]

I'm almost sure that's kind of an (almost) unnoticed side effect left over from the early stages of syntax experimentation; a transition from gosub to genuine subprocedures. Used to have some such in FBSL BASIC myself.

GOSUB was *the* thing when a function definition was still a single statement.

Jumping into a SUB or a FUNCTION just seems like a recipe for disaster to me, but what do I know - if it works  for you, why not abuse the syntax all you want?

[Charles Pegge]

I'm keeping gosub because (when used internally) all the caller's local/static variables remain visible. I really missed it in FreeBasic.

[Mike Lobanovsky]

FBSL BASIC allowed functions within functions (sort of "closures"). The "parent" function's locals and statics were accessible from its "children". The "children" didn't have access to each other's locals or statics but could call other "children" of the same "parent" and all higher-level procedures. The "children" were not visible from outside their "parent". This hierarchy was a by-product of FBSL implementation of classes and namespaces.

[Charles Pegge]

A scope block in subroutines will enable them to deploy their own private locals and statics.

[JRS]

I didn'r realize you guys were talking about a FUNCTION definition within a FUNCTION definition. This is the best SB can do with FUNCTION/MODULE scope.

Code: Script BASIC

1. MODULE Class
2.  
3. a = 1
4.  
5. FUNCTION One(a)
6.   CALL Two(a)
7.   a += 1
8.   One = a
9. END FUNCTION
10.  
11. SUB Two(a)
12.   PRINT a, "\n"
13. END SUB
14.  
15. END MODULE
16.  
17.  
18. PRINT a, "\n"
19. PRINT Class::a, "\n"
20. PRINT Class::One(2), "\n"
21.  

jrs@jrs-laptop:~/sb$ scriba functest.sb
undef
1
2
3
jrs@jrs-laptop:~/sb$


FYI:  Although the use of a MODULE prefix isn't required, main is the start MODULE.

Code: Script BASIC

1. main::a = 1
2.  

How one might do a direct assignment to the main MODULE global variable from another MODULE.

[JRS]

I'm keeping gosub because (when used internally) all the caller's local/static variables remain visible. I really missed it in FreeBasic.

We should have a cool icon for the docs that represents Charle's special language features.

[Mike Lobanovsky]

Code: Script BASIC

1. MODULE Class
2. ....

This basically looks like a NAMESPACE whereby you can call its member functions through the :: notation from the outside of that namespace.

The "functions within a function" ("closures") cannot be called from outside their parent function, only from the parent function code and from their siblings within that parent. The parent's own local and static variables are accessible to all its children down to the deepest nested level ("closures" can also be infinitely nested becoming "parents" to their own "children") but not vice versa.

That was the first step towards true encapsulation that already allowed the portions of app code to have neat formatting based on the parent/children's functional purpose.

The gosubs' host and portions of code all share common variables that aren't isolated from one another in any way and cannot therefore reuse the variables' names for their own "local" purposes in a gosub. ...

[ADDED] ... unless the language has a SCOPE directive, like Charles has noted above, to arbitrarily limit the visibility of variables to within the scope bounds.

[Aurel]

I don't want to dive into the deep explanation
but GOSUB is good in first place on the begining of program like i use it
with gloabal scope..

GOSUB InitProgram
GOSUB InitData
...

Main program
....
....
...
....

SUB Initprogram
---
END SUB
SUB InitData
----
END SUB