GOSUB VS SUB

[TempodiBasic]

Hi guys
GOSUB vs SUB.... mmmmh you loose FUNCTIONs!
:-)

[TempodiBasic]

Sorry I loose the point of discussion...

Pro               Contra
GOSUB            SUB Name (parameters)
                          CONST costants
                          DIM/SHARED global variables
                          DIM/REDIM Local_variables (STATIC)
                       
Label:                 .............
...                       EXIT SUB
...                       .............
RETURN            END SUB


Well in my little experience, I started to program in Qbasic/QB so I have no practice of GWBASIC and C-64 BASIC but only a referred terrorism versus GOTO and its child GOSUB!  Nevetheless reading of old BASIC there was a massive use of GOTO... but I don't know if that BASIC had also GOSUB, SELECT CASE, DO LOOP UNTIL, DO WHILE LOOP, IF THEN ELSE nested...., moreover I read that Pascal rose up to win the massive use of GOTO, but in its keywords there is the same GOTO :-)
In my practice I started using SUB and FUNCTION and when I went near the concept of flow event driven I approached to GOSUB by that Qbasic manages events like trap error, stick or pen input, music loop keyboard and timer events... and so on as all you still know.


surely I scare with the massive use of global variables... but also using SUB the parameters work like global variables that are changed into the SUB until if you pass parameter by value (not valid for string or typedef) or you use a local duplicate into the SUB. Moreover if you use an huge number of parameters it is very difficult to write code clear.
Nevertheless I like to use SUB versus GOSUB because i like to think to chunch the work into little works and so each task is performed by a block ... like the brick of lego... this is my habit but I can agree that with a solid habit I can get block of code working on its own also with GOSUB.
Thanks to read

[TempodiBasic]

It's like saying who's the greatest super hero, Batman or Superman?

@Pete
! do you forget Electra, DerilDevil and Flash, SuperGirl?
O_o

[Raven_Singularity]

In GW-BASIC (I can't speak for C64 BASIC), you didn't have to hack around with changing line numbers or GOTO/GOSUBing to random code blocks inserted somewhere when you "ran out" of numbers; all you had to do was RENUM your program - you could even renumber sections of your program; see https://www-user.tu-chemnitz.de/~heha/viewchm.php/hs/gwbasic.chm/RENUM.html

Well, if I had known about GW-BASIC "RENUM," I could have saved myself hours of hardship!  The books/magazines I read about BASIC did not mention this command.  Too bad.

I wonder how many other early BASIC programmers knew about RENUM?

[freetrav]

Nevetheless reading of old BASIC there was a massive use of GOTO... but I don't know if that BASIC had also GOSUB, SELECT CASE, DO LOOP UNTIL, DO WHILE LOOP, IF THEN ELSE nested...., moreover I read that Pascal rose up to win the massive use of GOTO, but in its keywords there is the same GOTO :-)

GW-BASIC and similar didn't have SELECT CASE or DO UNTIL, but some did have WHILE...WEND (GW definitely did, but AppleSoft, for example, didn't), which was functionally equivalent to DO WHILE. IF...THEN was common; IF...THEN...ELSE was not - but it did exist.

The nearest thing to SELECT CASE was ON...GOTO/ON...GOSUB, which was very limited by comparison - e.g., ON X GOSUB 100, 200, 300 would only work if X had an integer value of 1, 2, or 3; if X=1 it would GOSUB 100; if X=2 it would GOSUB 200; if X=3 it would GOSUB 300, otherwise it would just fall through to the next line.  Minimally adequate, but no more than that.

Pascal's GOTO was very restricted compared to BASIC's; not only did you have to declare the label before using it, but you couldn't use GOTO to break out of a block structure. In reality, that was enough to make GOTO almost useless in Pascal, and I don't think I ever saw it actually used in a program that wasn't a contrived textbook example specifically to show how the statement worked.

[freetrav]

Well, if I had known about GW-BASIC "RENUM," I could have saved myself hours of hardship!  The books/magazines I read about BASIC did not mention this command.  Too bad.

I wonder how many other early BASIC programmers knew about RENUM?

Not intended to be snarky, but ... any of them that really READ the BASIC manual.

[Raven_Singularity]

Not intended to be snarky, but ... any of them that really READ the BASIC manual.

I started programming C=64 BASIC when I was 9 years old, GW-BASIC a couple years later.  Nobody I knew in that era knew about RENUM, but we were just kids experimenting.  I got into C=64 BASIC because I saw someone use POKE statements to make the screen flash random colours and scroll text up the screen.  It was the most awesome tech novelty I had ever seen, so I promptly memorised the commands he used.

I did have a GW-BASIC book at that time which I read through, but I don't remember seeing RENUM in it.

[SMcNeill]

C64 BASIC didn’t have  RENUM command; it wasn’t added until the last version of C128 BASIC (floppy disk version, I think — maybe some old cartridges). 

GW-BASIC had RENUM, but I never saw anyone use it seriously.  It was rather silly the way it worked.

RENUM 1000, 900, 20 —- This was a valid command that made no real sense without reading and rereading the documentation over and over....

RENUMber starting with 1000, any number >= 900, and count by 20s...

Everybody got the first and second values screwed up, and RENUM killed code more than it fixed it.  Everybody I know, who programmed back in the day, simply used GOTO/GOSUB to scrunch new “blocks” out to insert new code — thus leading to spaghetti code, as we call it now.

[MWheatley]

C64 BASIC didn’t have  RENUM command; it wasn’t added until the last version of C128 BASIC (floppy disk version, I think — maybe some old cartridges). 

GW-BASIC had RENUM, but I never saw anyone use it seriously.  It was rather silly the way it worked.

RENUM 1000, 900, 20 —- This was a valid command that made no real sense without reading and rereading the documentation over and over....

RENUMber starting with 1000, any number >= 900, and count by 20s...

Everybody got the first and second values screwed up, and RENUM killed code more than it fixed it.  Everybody I know, who programmed back in the day, simply used GOTO/GOSUB to scrunch new “blocks” out to insert new code — thus leading to spaghetti code, as we call it now.

Yes.  I never trusted RENUM.  And parts of my PhD were written in BASIC, so that lack of trust mattered.

Malcolm

[TempodiBasic]

here https://www.qb64.org/forum/index.php?topic=1287.0 an example of mine to show a slight difference in the number of variables and in the way to manage data between SUB vs GOSUB

[Jack002]

*edit* never mind. Reply to a less than last post

[Raptor88]

While programming, I discovered a reason why GOSUB should be used.

Code: QB64: [Select]

1. DIM x AS INTEGER
2. x = 100
3. GOSUB PrintStats
4. CALL PrintStats2
5. END
6. '========== SUBROUTINES ==========
7. PrintStats:
8. PRINT "The value of x is: "; x
9. RETURN
10.  
11. SUB PrintStats2
12.     PRINT "The value of x is: "; x
13. END SUB

The print was:
The value of x is: 100  <== GOSUB printed the value
The value of x is: 0   <=== SUB did not print the value

I wanted a subroutine to print the values of 6 variables (statistics) at various points for troubleshooting.
Using SUB, the values were always zero, since I did not pass all of the variables to the SUB as arguments.
Using GOSUB, all of the values were printed without having to pass all of the variables as arguments.

It would be too unweildy to have to type 6 (or more) variables as arguments every time I inserted a CALL to the SUB.

So GOSUB should be used to print the contents of variables that have not been declared as SHARED.

Raptor88

[bplus]

Hi Raptor88,

A simple fix to your print SUB, giving it a parameter to pass it an argument to PRINT:

Code: QB64: [Select]

1. DIM x AS INTEGER
2. FOR x = 1 TO 10
3.     GOSUB PrintStats
4.     'CALL PrintStats2(x) '<<< yuck to CALL and ()'s
5.    PrintStats2 x
6. NEXT
7. END
8.  
9. '========== SUBROUTINES ==========
10. PrintStats:
11. PRINT "From GOSUB PrintStats: The value of x is: "; x
12. RETURN
13.  
14. SUB PrintStats2 (printThisNumber) '<<< Fixed with a parameter to pass PRINT and argument to PRINT
15.     PRINT "From PrintStats2: The value of x is: "; printThisNumber
16. END SUB
17.  
18.  

PS I don't usually use CALL so I don't have to put arguments inside ()'s

Everything inside a SUB is completely ignorant of variables and values from another part of program. It only knows what you pass it from outside or what is DIM SHARED in main code.

So another way to do this:

Code: QB64: [Select]

1. DIM SHARED x AS INTEGER '<<< if you share x, you don't need to pass PrintStats2 an argument
2. FOR x = 1 TO 10
3.     GOSUB PrintStats
4.     PrintStats2
5. NEXT
6. END
7.  
8. '========== SUBROUTINES ==========
9. PrintStats:
10. PRINT "From GOSUB PrintStats: The value of x is: "; x
11. RETURN
12.  
13. SUB PrintStats2
14.     PRINT "From PrintStats2: The value of x is: "; x
15. END SUB
16.  
17.  

[Raptor88]

Hi bplus,

Yes, both of the examples you posted are solutions.
For solution1, I didn't want to have to type 6 arguments for each CALL.
For solution2, I thought not making all of my variables global using SHARED was the way to go.
I'm using CALL for now as a novice, to make it obvious to me it is a call to a SUB.  I may use your method later for less typing.

Thanks for taking the time to help.  I do appreciate it,
Raptor88

Hi Raptor88,

A simple fix to your print SUB, giving it a parameter to pass it an argument to PRINT:

Code: QB64: [Select]

1. DIM x AS INTEGER
2. FOR x = 1 TO 10
3.     GOSUB PrintStats
4.     'CALL PrintStats2(x) '<<< yuck to CALL and ()'s
5.    PrintStats2 x
6. NEXT
7. END
8.  
9. '========== SUBROUTINES ==========
10. PrintStats:
11. PRINT "From GOSUB PrintStats: The value of x is: "; x
12. RETURN
13.  
14. SUB PrintStats2 (printThisNumber) '<<< Fixed with a parameter to pass PRINT and argument to PRINT
15.     PRINT "From PrintStats2: The value of x is: "; printThisNumber
16. END SUB
17.  
18.  

PS I don't usually use CALL so I don't have to put arguments inside ()'s

Everything inside a SUB is completely ignorant of variables and values from another part of program. It only knows what you pass it from outside or what is DIM SHARED in main code.

So another way to do this:

Code: QB64: [Select]

1. DIM SHARED x AS INTEGER '<<< if you share x, you don't need to pass PrintStats2 an argument
2. FOR x = 1 TO 10
3.     GOSUB PrintStats
4.     PrintStats2
5. NEXT
6. END
7.  
8. '========== SUBROUTINES ==========
9. PrintStats:
10. PRINT "From GOSUB PrintStats: The value of x is: "; x
11. RETURN
12.  
13. SUB PrintStats2
14.     PRINT "From PrintStats2: The value of x is: "; x
15. END SUB
16.  
17.  

[TempodiBasic]

Hi Raptor88

I agree with you that each one takes own method to code.

I don't agree with this

For solution2, I thought not making all of my variables global using SHARED was the way to go.

because with GOSUB all your variables are already in the main and are Global!
So with or without SHARED you use global variables.
A different kind of issue is that rised up by Fellippe
you can make a GOSUB inside a SUB or FUNCTION,

 but in this case the variables used in the GOSUB are those Global with SHARED into the main and those local of the SUB where GOSUB is.