BASIC odities in QB64 or using REM in IF\THEN\ELSE

[Cobalt]

this line is perfectly accepted in the IDE, whether or not it works right I don't know yet,

 IF Result%% THEN REM do nothing: ELSE Player(0).On_Ground = FALSE

but this line results in a IF without END IF error

 IF Result%% THEN ' do nothing: ELSE Player(0).On_Ground = FALSE

its part of my Mario clone ground collision routine, if RESULT is true player is on the ground which keeps gravity from pulling him down more, but if there is no collision then the player must not be on the ground anymore.

I realize I can leave the comment out and just have THEN ELSE blah, blah

but that just look grammatically wrong to me and bugs me. I could break it up too but I'm trying to cut down on extra lines to

keep the code more readable as well. I could also have it keep setting Player(0).On_Ground = TRUE but that is handled

elsewhere and I'm not sure I want it handled in the collision yet, as it causes small issues within the Gravity routine and how it

handles that last move from free fall to landing. when the final distance is less than a Terminal_Velocity value.


SOOOoooo what I'm am curious about is why allow REM to work just fine but moan and groan about using " ' " within an IF/THEN/ELSE statement?

Not that I think anything really needs done about it, as there are more important things in QB64 like ARRAYs in UDTs to figure

out but its late(for me anyway) and I'm tired and in a good deal of pain tonight and just thought I might throw this out there.
 

[SMcNeill]

This was decided over at [abandoned, outdated and now likely malicious qb64 dot net website - don’t go there]:  REM is a COMMAND; ‘ is a remark.

IF whatever THEN REM  <— this is a perfectly valid, stand-alone line of code.  REM is a command, which you execute if the condition is met.

IF whatever THEN ‘  <— this will toss an IF WITHOUT END IF type error, as you ended your line of code with out any command to execute after the THEN.

WHY folks wanted it this way, I dunno.  I wanted both forms of syntax to be equivalent to each other, but they’re not.  REM is a command (to treat everything following as a remark), whereas ‘ is a remark.

[FellippeHeitor]

WHY folks wanted it this way, I dunno.

Cause that’s how it works in QB45 and that’s our original model.

[Cobalt]

Oh, okay. Thanks guys, now I know.

More of that useful, yet mostly lost, information from .NET

[TempodiBasic]

Hi guys

I can confirm that this is an eredity of Qbasic and QB45 where REM is a command and ' is a remark (no command)
so the logic  syntax , that all we know,  is IF this THEN command

PS
Yes also I have fallen in this bug of language....  IMHO if we change it, it is not more QB compatible.
Another QB's bug is brought from INSTR that gives always positive answer to search a null string "" in a string, so you must remember to check before that string is not  null (for example   in this code following

Code: QB64: [Select]

1.  WHILE in$ = INKEY$
2. IF INSTR("WASD", UCASE$(in$)) THEN ExecuteCommand
3. WEND
4.  

ExecuteCommand will be called both when user press no inkey both when user press WASD)

[Bert22306]

Yes also I have fallen in this bug of language....  IMHO if we change it, it is not more QB compatible.

Me too. Does anyone know for sure if this was a MS QB bug, or if it was intentional? Because otherwise, I'm totally with Steve on this. Interesting philosophical question, whether MS QB bugs should be carried over, in the interest of compatibility.

[SMcNeill]

Me too. Does anyone know for sure if this was a MS QB bug, or if it was intentional? Because otherwise, I'm totally with Steve on this. Interesting philosophical question, whether MS QB bugs should be carried over, in the interest of compatibility.

Bugward compatibly!

[FellippeHeitor]

This discussion is pointless. It’s never been a bug in QB4.5 to treat both comment styles differently and it is proper that we keep compatible with what QB4.5 did, that case included.

 [ You are not allowed to view this attachment ]  

Just as reference, here’s REM in Visual Basic, also working in the exact same way we have implemented, *including the coloring*:

https://docs.microsoft.com/en-us/dotnet/visual-basic/language-reference/statements/rem-statement

And here’s an alternative page talking about the command - even fixing MS’s incorrect example of REM without a separating colon:

https://www.oreilly.com/library/view/vbnet-language-in/0596003080/re279.html

If you use the Rem statement on the same line as program code, a colon is required after the program code and before the Rem statement. For example:

Code: [Select]

Set objDoc = MyApp.MyObj : Rem Define the object
                           Rem referenceThis is not necessary when using the much more common apostrophe:

Code: [Select]

Set objDoc = MyApp.MyObj    ' Define the object reference

[FellippeHeitor]

BTW, @Cobalt, this:

Code: QB64: [Select]

1.  IF Result%% THEN REM do nothing: ELSE Player(0).On_Ground = FALSE

Is the same as:

Code: QB64: [Select]

1.  IF Result%% THEN REM

The ELSE part is in a comment too and will never be run. What you probably wanted is:

Code: QB64: [Select]

1.  IF NOT Result%% THEN Player(0).On_Ground = FALSE

This, of course, assuming your TRUEs are -1 and your FALSEs are 0.

[TempodiBasic]

fine Bugward!
But who do think that QB/Qbasic is with no bug?
It is clear that bringing forward QB line we bring its Bugward compatibility!
The same is with all programs... including the programming language (compiler + parser + interpretrer+ code machine like JVM)
it is the world of informatic! No less No more!

IMHO to improve the language there are the NEW keywords that starts with _ , so who doesn't like the old QB's bugs can go over with these new keywords.

Thanks to read