Declined SUB ... ENDSUB

[Rick Reinckens]

i would like to see SUB ... ENDSUB

This doesn't have to be some substantial new functionality, it could basically be the same as GOSUB {LABEL}. ENDSUB could have the same functionality as RETURN without an argument.

This would basically be to make code more readable and more in line with other languages such as Excel VBA. it also would make it easier to distinguish GOTO target labels from GOSUB labels.

I would suggest that anything after ENDSUB be ignored--I normally would want to have the name of the sub, e.g.

GOSUB DISPLAY_DATE

SUB DISPLAY_DATE
    ECHO %_date
    PAUSE

ENDSUB DISPLAY_DATE

Related possibilities would be that a SUB command on a line by itself will display a list of all SUB routines, and/or within a SUB the command SUB on a line by itself will display the name of the current SUB (for development/troubleshooting purposes).

Alternatively, SUB by itself within a SUB could list all SUBs but have some indicator of the current SUB such as ***.

Related to that SUB /P could display the name and then PAUSE.

 

[AnrDaemon]

CALL or just spell the name of the sub directly.

 

[vefatica]

You can put text after RETURN.

v:\> type test.btm
gosub foo
echo I'm back.
quit

:foo
echo Hello world!
return (endsub foo)

v:\> test.btm
Hello world!
I'm back.

You can also

alias endsub return

v:\> type test.btm
alias endsub return
gosub foo
echo I'm back.
unalias endsub
quit

:foo
echo Hello world!
endsub foo

v:\> test.btm
Hello world!
I'm back.

 

[Rick Reinckens]

PLEASE STOP RECOMMENDING ALIASES AND OTHER CUSTOM APPROACHES!

As I've pointed out REPEATEDLY, the problem with ANY custom approach is IT'S NOT STANDARD. Also, there's no Help and no programming examples.

I KNOW things can be done with loads of custom coding, especially aliases. But then nothing is compatible with anything else, because each implementation--even by the same programmer--will wind up different.

When I recommended the Library system I pointed out that I had already used an ALIAS LIBRARY=GOSUB. Somebody else might use ALIAS LIB=GOSUB, and someone else might use ALIAS LIB_BTM or ALIAS LIBRARY_BTM etc.

And if code is copied for re-use there's always the potential that two different source programs each define the same ALIAS differently and the programmer doesn't notice. My various programs have a set of display aliases:

ALIAS USE_COLOR_MAIN=BLUE ON BRIGHT WHITE
ALIAS USE_COLOR_EMPHASIS=GREEN ON BRIGHT WHITE
etc.

Except in some programs I use different colors for USE_COLOR_EMPHASIS.

imagine what a mess it could make if ALIAS ENDSUB or ALIAS SUB changed in the middle of a program.

 

[Rick Reinckens]

CALL or just spell the name of the sub directly.

That only deals with the calling part, not with the actual subroutine part.

SUB ... ENDSUB would improve readability of the actual subroutine. Also, it makes it more similar to other languages. If programmers in general felt that an ENDSUB, ENDPROC or ENDFUNC marker wasn't particularly helpful, they wouldn't add them to most of the languages developed after DOS batch language (which eventually evolved to CMD, of course.)

The same goes for SUB. It makes it clear it's the target of a GOSUB, not a GOTO, or an intentional unused label (maybe stuck in for development, testing, or troubleshooting purposes.

 

[vefatica]

PLEASE STOP RECOMMENDING ALIASES AND OTHER CUSTOM APPROACHES!

But you seem to want a custom approach ... because YOU like "SUB ... ENDSUB" better than ":LABEL ... RETURN".

 

[Rick Reinckens]

But you seem to want a custom approach ... because YOU like "SUB ... ENDSUB" better than ":LABEL ... RETURN".

But if it's added to the language, then it won't be a custom approach. That and bringing TCC more in line with other modern languages by what would be a fairly simple change to TCC are the whole point of adding it to the language.

And it's not I like. Frankly, I prefer PROC ... ENDPROC. But SUB ... ENDSUB is much more common in programming languages. :LABEL ... RETURN is the one that's oddball.

 

[vefatica]

:LABEL ... RETURN has been part of this product since the beginning (4DOS ... ~30 years ago). And I've been using it nearly as long as that. I'm confident that Rex won't change the old behavior. If he wants to duplicate it with a new, superfluous, and limited behavior, that's up to him. I just don't see any need for it; it doesn't add new capability and doesn't make anything any easier.

 

[Rick Reinckens]

:LABEL ... RETURN has been part of this product since the beginning (4DOS ... ~30 years ago). And I've been using it nearly as long as that. I'm confident that Rex won't change the old behavior. If he wants to duplicate it with a new, superfluous, and limited behavior, that's up to him. I just don't see any need for it; it doesn't add new capability and doesn't make anything any easier.

I'm not saying to change it, I'm saying to add SUB ... ENDSUB as an additional option.

Actually, it would make it easier when porting code to or from other languages or using code from another language as model. Plus, for people who mainly use other languages it will make TCC look a bit more similar to what they routinely use.

 

[Charles Dye]

Plus, for people who mainly use other languages it will make TCC look a bit more similar to what they routinely use.

Well, that's pretty much what we have now. GOTO and GOSUB/RETURN are already familiar to folks who use another language.

Spoiler: Well ....

Provided that language is BASIC, of course.

 

[Rick Reinckens]

By the way, in addition to SUB ... ENDSUB I also suggested possibly a SUB command.

From a coding perspective (i.e., coding TCC/TCMD itself) it seems like that would basically be something almost completely separate. If implemented, I think it wouldn't be used much--so although the suggestion has been made, it's probably one that shouldn't be seriously considered unless other folks can think of how it would be useful or suggest variations.

 

[Rick Reinckens]

Well, that's pretty much what we have now. GOTO and GOSUB/RETURN are already familiar to folks who use another language.

"Well ...." Provided that language is BASIC, of course.

Show me any other major language where labels are indicated by a colon instead of an unambiguous indicator like PROC, PROCEDURE, SUB, FUNC, or FUNCTION.

I'm not saying to replace GOSUB. I'm saying to allow a variation of the TARGET indicator, i.e., the label indicator for subroutines.

And ENDSUB just tends to stick out more and be clearer than RETURN. (And I wouldn't see a problem with allowing both RETURN and ENDSUB.)

Also, SUB ... makes it clear that it's a subroutine target. Currently there is no easy way to tell whether a label is intended as the target of GOTO or GOSUB other than to examine surrounding code looking for a RETURN.