Label before end sub is not accepted: needed at least one instruction

pik33

This compiles:

dim i as integer

i=0
testsub

sub testsub
if i<>0 then goto p999
i=i+1
p999:
i=i+1
end sub

This doesn't compile: unexpected end of line (at the commented out line)

dim i as integer

i=0
testsub

sub testsub
if i<>0 then goto p999
i=i+1
p999:
'i=i+1
end sub

Edit: 'loop' is also not allowed directly after a label.

ersmith

Parsing labels is really nasty, and I haven't found a clean way to incorporate them into the syntax that works for all cases. Probably I should just give up and introduce a "LABEL" keyword, and require writing something like "LABEL p999" instead of "p999:".

JRoark

@ersmith said:
…introduce a "LABEL" keyword, and require writing something like "LABEL p999" instead of "p999:".

YES. This. +1.

There is arguably a reason to keep labels, but not necessarily the “traditional” syntax that is associated with them. And that silly trailing colon has long baffled me since it is also used as a separator between statements on a single line.

My vote would be to kill both of these birds with one stone.

pik33

Treating labels as something like typed variable may also be a solution. & is not used in Basic so maybe this:

declaring a label like a variable as in Pascal::

dim thelabel as label

and then simply use it

thelabel: do something

When the declaring is switched off via option,

thelabel&: do something

This would still look like Basic while may make parsing easier

evanh

Last time I coded a full program in Basic the language did not support line numbers but it also did not support full subroutines either. All branching, whether GOSUB or GOTO, was to labels in effect. It was up the coder to manage GOSUB/RETURN levels.

Labels all started with #. Presuambly they had to be on a separate line. Here's a single routine from that program that had both GOTO and RETURN for exiting. I remember the mechanism being very effective:

#inputpass
  IF Key <> 13 THEN RETURN
  IF Num = PassA THEN Passed = Num : Page = 4
  IF Num = PassB THEN Passed = Num : Page = 5
GOTO pages

JRoark

@pik33 said:
& is not used in Basic so maybe this:

This gets a bit tricky. The “&” symbol is used in BASICs, albeit inconsistently between vendors/versions.

In many BASICs (Flex included), it represents a hex value when used on the right side of the assignment and the value is a constant:

myVar = &hFF ‘set to 255

It is used in Microsoft BASICs as a variable type specifier for “long”:

myLong& = 1234567890

It is also used in Microsoft BASICs (VB5/6 come to mind) as a faster string cat operator:

myString$ = a$ & b$ & c$

And just to really muddy the sybtactic waters, it is used in some embedded BASIC versions as shorthand notation for a bitwise AND:

myVal = a & b

IMHO it is probably best to leave “&” out of consideration for any label use.

I’d also not suggest using DIM to distinguish a label. Historically DIM “allocates space” (yeah, I know, but this is how DIM has evolved and was taught), so maybe using DECLARE or something similar would be better?

ersmith

I think I may have labels sorted out -- one problem is that I was trying to treat identifier labels like "foo:" and old style line numbers the same. The line numbers will continue to have some weird restrictions (e.g. they may not work before END or LOOP) but identifier labels should be more sensible now. The code is checked in, and I hope to have a new release in a few days.

pik33

I tried line numbers: they work. (5.9.6) The attached code does nothing useful but compiles.

5 option implicit
10 for i=1 to 100
20 j=1
30 do
40 j=j+1
42 kwas
43 gosub 139
45 print j
50 loop until j=5
60 next i
70 sub kwas
80 k=0
85 if j=1 then goto 120
90 do
100 k=k=1
110 loop until k=10
120 end sub
139 return

jmg

@ersmith said:
I think I may have labels sorted out -- one problem is that I was trying to treat identifier labels like "foo:" and old style line numbers the same. The line numbers will continue to have some weird restrictions (e.g. they may not work before END or LOOP) but identifier labels should be more sensible now. The code is checked in, and I hope to have a new release in a few days.

Sounds great.
It's nice if P2 BASIC can keep somewhat consistent with other Basics, as that allows code blocks to be tested and dropped in, and FreeBASIC looks like a useful well documented example.
https://www.freebasic.net/
https://documentation.help/FreeBASIC/ProPgLabels.html