Roku Developer Program

[belltown]

You totally missed my point.

I give up.

[EnTerr]

"belltown" wrote:
You totally missed my point.
I give up.

You mean i did not respond to the end of your message when you stretched word meanings, by taking block-IF being called in some doco places "multi-line" (to distinguish it from one-liner-IF) and then combined it with your own musing that only single-line statements can be combined with ":" for a single line - to come up with this?

"Since, by definition, multiple lines cannot occupy a single line, a multiple line statement cannot be used after the line continuation character given the above definition of the line continuation character (multiple statements on a single line)."

I chose not to, because you did a silly word-play there. And also since i showed that WHILE and FOR are as "multi-line" as IF is, thus the 1st example

i = 5: for j = 1 to 5
    ? i + j
end for

shouldn't work by your logic since "multiple line statement cannot be used after the line continuation character" and "multiple lines cannot occupy a single line".
Well, we tried it and it works, so umm... it seems you mis-interpret the meaning of ":" to reach desired conclusion (block-IF does not work after ":" ) ?

PS. I like that you venture off the beaten path, like question whether FOR/ENDFOR is a single or two separate statements (btw, the first programming language i learnt was a version of BASIC where FOR and NEXT were two separate statements and matching was done runtime, so funny things may happen jumping in and out of loops with GOTO). But you should check your theories too, not select one just because they fits the intended conclusion

[Komag]

I've wrangled with single line vs multi line IF handling, and it is definitely a unique beast. Different combinations of nested IF's, some single line and some multi-line, have to be handled with kid gloves I've found. Things that "should" work sometimes didn't. I don't know if I would call it a bug, just picky maybe.

[EnTerr]

"Komag" wrote:
I've wrangled with single line vs multi line IF handling, and it is definitely a unique beast. Different combinations of nested IF's, some single line and some multi-line, have to be handled with kid gloves I've found. Things that "should" work sometimes didn't. I don't know if I would call it a bug, just picky maybe.

It seems very tricky at first indeed. But "there is method to the madness" and when you get the knack of it, there should be no trouble.

Surely it could have been explained better - or at all - in the documentation. Currently there is no explanation whatsoever on the differences, instead one is left to guess it from the two examples. I suspect whoever wrote thought there could be only one way to guess it, well obviously duh... aa-and that's not the case! But it is easy to have blind spots when one is so close to the subject matter, can't blame them.

At first i wondered too - how does interpreter decide which one to stick with - could it be by look-ahead to see if `then` or `:` or `else` are used on the same line? That is not it though - `then` is unabashedly optional, can be skipped and rather it checks to see if there is another statement on the same line AFTER the IF. You can put any simple statement (that is, a non-block statement - FOR/WHILE are excluded, at least in current incarnation) on the same line following IF and that makes it a 1-liner; otherwise a block-IF will be assumed.

It was not a wise choice since causes confusion. If i were designing the language (and had to stick with BASIC), i would have distinguished the two IF forms more - likely by mandating that having "THEN" afterwards means 1-line IF and multi-line one is without `then` - just to be extra clear on who is who. But it is too late to fix it now.

Let me try to formalize the rules:

• At least one statement following IF on the same line determines it to be a 1-line-IF, otherwise it is a block-IF.


• THEN is optional after (any kind of) IF and does not affect the meaning


• Only simple-statements can partake in one-line-IFs (no block IF/FOR/WHILE)


• Multiple statements can follow IF on the same line, followed by an optional ELSE clause


• If ELSE keyword is present in 1-line-IF, it must be followed by one or more statements

PS. I just realized i am 1 letter short of spelling "ATOMIC" in acrostic. Any ideas for a "C"-rule? :mrgreen:

[Komag]

I know all that now (good summary!), but there's something odd going on when mixing/nesting one-line versions and multi-line versions. I can't remember exactly the example I had to re-work in my program - I should try to recreate the problem I found...

(for ATOMIC...)
(Care must be taken to...)

[EnTerr]

Roku engineers -
is there a chance you can fix this issue with the block-IF statement?
(the one where block-IF being non-first on the line causes compile error)

I'll "make you a deal" 🙂 - if this gets fixed, i'll release a profiling script for BRS.
That is, a script that instruments channel's source code so that after a run, number of executions and times can be tallied per line.

I know it's not a tit-for-tat game but let me throw that offer as a bonus. An icing on the cake, if you will. Or opportunity to tell me to "put up or shut up". Because one, fixing that edge case is the right thing to do and shouldn't be hard. And two, it will make it easier to profile code, which comes handy in time-critical (like games) or data-processing-intensive (which most things appear to be on fw3) apps. Seems a win-win to me.

[Komag]

Here's an example:

FOR a=0 TO (Sq[0].Count()-1)
	IF Sq[0][a].spriteDraw <> invalid THEN Sq[0][a].spriteDraw.Remove()
END FOR
FOR b=0 TO (Sq[1].Count()-1)
	IF Sq[1][b].spriteDraw <> invalid THEN Sq[1][b].spriteDraw.Remove()
END FOR

That works just fine. But this:

FOR a=0 TO (Sq[0].Count()-1): IF Sq[0][a].spriteDraw <> invalid THEN Sq[0][a].spriteDraw.Remove(): END FOR
FOR b=0 TO (Sq[1].Count()-1): IF Sq[1][b].spriteDraw <> invalid THEN Sq[1][b].spriteDraw.Remove(): END FOR

That won't compile, throws off multiple syntax errors.

This also doesn't work:

FOR a=0 TO (Sq[0].Count()-1): IF Sq[0][a].spriteDraw <> invalid: Sq[0][a].spriteDraw.Remove(): END IF: END FOR
FOR b=0 TO (Sq[1].Count()-1): IF Sq[1][b].spriteDraw <> invalid: Sq[1][b].spriteDraw.Remove(): END IF: END FOR

Gives same syntax errors

Apparently, both single-line and block IF THEN don't like being stuck into fake new lines :

[Komag]

Maybe something has changed, or maybe this is not exactly the same situation, but I just noticed that this code of mine works fine:

	IF	  dir = 1: act = TRUE ' Right ' Will act similar to Select, to expand menu to submenu for any main item
	ELSEIF dir = 3: back = TRUE ' Left ' Will act similar to Menu, to close a menu level or exit menus altogether
	ELSEIF dir = 0: sel = sel -1:	IF sel < 0 THEN sel = menuMax ' Up
	ELSEIF dir = 2: sel = sel +1:	IF sel > menuMax THEN sel = 0 ' Down
	ELSEIF dir = 4: act = TRUE ' Select/OK
	END IF

I suspect it's a different situation