Label before end sub is not accepted: needed at least one instruction
pik33 Posts: 2,013
edited 2022-01-17 14:18 in BASIC (for Propeller)
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.
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:".
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.
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
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:
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?
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.
I tried line numbers: they work. (5.9.6) The attached code does nothing useful but compiles.
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.