Closed EricCarrGH closed 11 months ago
Hi!
Thanks for your contribution!
Sadly, this is more complicated, and does not always work, because the abbreviation for ENDIF
is already E.
, so it also covers the EN.
case.
In the cross-compiler, this works because the parser roll-backs on the error "ENDIF without an IF", and then tries the "ENDPROC" alternative, that works.
But currently the native compiler does not try as hard, and gives a "loop error" instead. Try this program, with your patch it works in the cross-compiler but not in the native compiler:
PR.A B
IF B
? "OK"
EL.
? "NO"
EN. ' This is ENDIF
EN. ' This is ENDPROC
@A 0
@A 1
As to why the native compiler does not try this parsing - it is because the error reporting is not as good, so I decided that it is better to simply error out instead of giving an error later that could be very hard to understand. The "loop error" is one of the errors that the compiler reports. Changing this will require a big rewrite of the loop error handling.
Have Fun!
@dmsc ah, yes that makes sense. Thank you for the explanation on the native compiler limitation.
It also makes sense that the language compatibility should be identical between native and cross platform compilers.
One of the great things about FastBasic is the ability to abbreviate commands for less typing and reducing code size.
PROC
can shorten toPR.
andENDPROC
toENDP.
, which is on the longer side for an abbreviation.I submit for your consideration, a proposal for the next release of FastBasic :
Reduce
ENDP.
toEN.
, which would save 2 characters. The savings greatly helps when a program contains a lot of Procs.It is backwards compatible with code that contains with
ENDP.
, so is not a breaking change.The following example compiles and runs fine with this change: