Request for better parsing of IF statements

[Robert Hodge]

I have recently run into some peculiar responses to incorrect IF syntax. Basically you will get the IF without END IF message if you do "dumb" things like

IF IF condition THEN
statement
END IF
or

IF condition1 THEN
statement2
ELSE IF condition2 THEN
statement2
END IF
The IF IF doesn't happen too often, but ELSE IF has recently been the bane of my existence.

I am wondering if, perhaps during a preprocessing phase, the source could be examined, and if a line begins with ELSE and is immediately followed by IF, it would be understood to mean exactly the same as ELSEIF and not (eventually) treated as an error.

Could this be done without breaking the syntax of IF as a whole? Is there ever a reason to use ELSE IF as two separate words and NOT have it mean ELSEIF?

Along with this (or instead of it, if you can't do what I am describing above), is there any way that TB could "narrow down" where the "likely" place is that the missing END IF could have originated? For example, if I have a 100-line program, and everything is OK as of line 50, and then line 51 contains an IF statement that doesn't get closed, it would really be helpful if I knew that the problem couldn't have happened prior to line 50. This would speed up the process of searching for the cause of the typo.

[ReneMiner]

Therefor I made myself some "hobbyistic" Spellchecker (http://www.thinbasic.com/community/showthread.php?t=12130&highlight=spellcheck) - if it's some structural error as missing "then" or some "uneven if-thing" or even some sub/function-thing it tells you the starting line but stops checking then because of the structural error. Just drag the file to check into the window or make use of the posted function if you don't like the GUI/ want to use it built-in elsewhere...

[Robert Hodge]

I am less sure about ELSIF and ELIF than I am about the other forms. But allowing for ELSEIF and ELSE IF seems like a good idea.

The ENDIF thing is understandable. It seems sort of odd that you have to say ELSEIF but END IF. It's not really consistent.

Coming from a PL/1 and Rexx background, the whole Basic approach where wyou have WHILE/WEND, REPEAT/UNTIL, DO/LOOP, etc. seems like the language design was just thrown in as an after-thought. It would have made more sense to end everything with END, but it's like they were in a hurry to add structured programming constructs and were not too fussy how they looked. (This isn't TB's fault; every modern Basic does it like this.)

There is another thread open about making all the blocks have uniform END closures, but I'm not holding out much hope of that getting done.

[Charles Pegge]

End if, end do, end while etc is clearer than plain 'end', especially within in large nested blocks. But for those who like uniform block demarkation, curly braces are also a possibility :)

[Robert Hodge]

My thoughts about "uniform" closures is that block ought to all be closed the same way.

In PL/1, everything ends with END, and C uses { and }. While "uniform" it doesn't really tell you very much, so that if you are trying to keep track of which block is closed, it can start getting hard if you have deeply nested structures.

By 'tagging' blocks, it provides confirmation, like the "IF" in END IF. But when your IF "block" only has two lines in it, the confirmation is not really needed, and it just becomes a burden to be forced to confirm the obvious.

I believe a better approach is to all the confirmation keywords to be optional, so that you can use them when it improves documentation, while omitting them when it gets in the way, like this:


IF COND1 THEN
IF COND2 THEN
statement1
statement2
END
END IF

When blocks are "small", the 'tag' on the END should be optional, because it's obvious what is being ended. As blocks get larger and more nested, confirming the block type being closed is more important.

The other aspect of uniform blocks is to use END to end all blocks.

That would mean that FOR would be ended by END FOR, not by NEXT. Or at least, END FOR should be allowed instead of NEXT. A WHILE block could be ended by END WHILE as well as by WEND.

The REPEAT/UNTIL block would be harder to convert to a uniform style and still maintain backward compatiblity. The best that could be done perhaps is to convert REPEAT/UNTIL into DO/UNTIL/END DO. This would take some careful planning but it ought to be possible to do.

[ReneMiner]

since "END"- keyword does not mean that -"End execution now"- like other basic languages, its completely free for use alone and it might just work this way:



Sub X()

If A Then
If Not B Then
'...
End
ElseIf B Then
Select Case C
Case 1

Case 2
End
End

End

It would not even need to be followed by If, Sub nor Select since it always ends the current in the row unconditional. Otherwise the programmer has made a mistake.

I'd prefer the way to write it all in one word as "EndIf" anyway and I would like it too, if there was an "EndSelect", "EndSub", "EndFunction".
"EndFor" as an Alias for "Next" could work because the condition is within the For...To-Line, or even just "End" on a single codeline which could be replaced by a single dot .
But I could not imagine "EndWhile" instead of "Wend" if there were "ElseWhile" and/or "WendIf", no "End Do" as long as there's "Loop While/Until"



______________________________________________________________________________________________
OT:
For the enhanced IF ("Select Case Abusement" - sorry - I don't find the thread anymore - but this is about IF too somehow)
perhaps it could be done just by replacing "Case" alike


Select Truth ' could replace "Select" also with "Find" here
Truth expression1
'statements
Truth expression2
'statements
Truth Each ' (of the above- would that work as Select in Java?)
' statements
Truth None ' guess this has to be last
' statements
End'however

[ReneMiner]

the Else If I don't like and I can imagine that this could lead to some unexpected errors, because of line-continuation without underscore. Have a look:



If A Then
'...

Else

If B Then

'...
where are we now?