buggy(?) UNTIL and documentation comments (SOLVED)

[clamzonprozac]

Here's something that doesn't work as expected: the UNTIL in this code example gives two differing results depending on the order of
the conditionals. As a sanity check I've included a corresponding IF that gives a correct (expected) result.
REM---------------------------------------------------------------------------------------------
GLOBAL test_table$ = "|aa,bb,cc,dd|ee,ff,gg|hh,ii|"
GLOBAL i, test_table_len TYPE int
test_table_len = LEN(test_table$)

FUNCTION until_test$()
LOCAL c$,s$
s$ = ""
REPEAT
c$ = MID$(test_table$,i,1)
s$ = s$ + c$
INCR i
UNTIL (c$ = ",") OR (c$ = "|") OR (i = test_table_len -1 )  :  'swap the "," and "|" to see what I mean
RETURN s$
END FUNCTION

FUNCTION if_test$()
LOCAL c$,s$
s$ = ""
LABEL repeat_me :
c$ = MID$(test_table$,i,1)
s$ = s$ + c$
INCR i
IF (c$ = ",") OR (c$ = "|") OR (i = test_table_len -1 ) THEN
RETURN s$
ELSE
GOTO repeat_me
END IF
END FUNCTION

i=2
PRINT until_test$()

i=2
PRINT if_test$()
REM----------------------------------------
However, instinctively, I've used three OR'd conditionals with UNTIL where as the documentation only tells of an equation being specified, and that seems a counter-intuitive restriction. Maybe I'm doing something horribly wrong?

 I also notice that REPEAT has an entry in the BaCon documentation but its partner, UNTIL, doesn't.

Speaking of documentation, it would be nice if more words were thrown at the ADDRESS keyword. As in explaining more about  its scope. Only GLOBAL variables, or can it  temporarily reference a variable on the stack? Any tricks one might want to know?

Thanks for the read, BR!
-Roger M.

[Pjot]

Hi Roger,

Thanks for your report. This problem does not occur in de Shell version of BaCon.

And indeed, the order in which the OR'ed conditionals occur should not make any difference. In any case, both the IF and the UNTIL (and a WHILE, for that matter) should deliver the same result.

The reason why this issue never occurred before is because of the extensive use of parentheses in combination with spaces. Though from syntactical point of view the code you are demonstrating is correct, most people do not use the parentheses, e.g.:

UNTIL c$ = "," OR c$ = "|" OR i = test_table_len -1


instead of:

UNTIL (c$ = ",") OR (c$ = "|") OR (i = test_table_len -1 )


Having said that, the latter should be working just as well. The fix was simply to make sure no redundant spaces appear in the conditional (something which indeed was taken care of by the Shell version). You can download this fix from here.

The reason why "UNTIL" does not occur as a separate documentation entry is because UNTIL is part of the "REPEAT/UNTIL" statement. So the "UNTIL" keyword is not a complete statement by itself.

The ADDRESS function simply returns the memory address of a variable or function. This could be a memory address in the stack of the current function (variable) or an address from the heap, depending on where the variable or function was declared. The returned address itself is treated as a plain unsigned integer number, which could be assigned to a variable of a similar type.

Take for example this code:

SUB key (NUMBER k, NUMBER x, NUMBER y)

   END

END SUB

SUB mainprog

   glutInitDisplayMode (GLUT_RGB | GLUT_DOUBLE)
   glutInitWindowSize(XSize, YSize)
   glutCreateWindow ("S T A R S")

   glutDisplayFunc (ADDRESS (draw))
   glutKeyboardFunc (ADDRESS(key))
   glutIdleFunc (ADDRESS(idle))

   glutMainLoop

END SUB


As you can see, the callback function for "glutKeyboardFunc" points to the address of the previous function "key".

HTH,
Peter

[clamzonprozac]

Thank you for the quick turn of a fix, as well as your comments, Peter! ... works as expected!