An element of the original design of JBasic is that each statement is compiled somewhat independantly, with no knowledge of the statements that came before or after it. In fact, linking all the statements together in one large executable bytecode string (with internal branch references resolved) came along mid-way through the development.
A big advantage of this is that each statement is responsible for compiling its code and this can be cached in each statement object; only at link time are they stitched together. When a new statement is added or deleted, the individual statement(s) affected are recompiled or deleted, but the rest of the program is unaffected. A final link phase takes care of last-minute bindings.
I’ve long wanted to add a multi-line IF statement, but this violates the basic rules - such a construct would theoretically have to know about the context of other statements. But a user request for this feature got me thinking about it anew, and the solution can be much simpler than I had previously thought about.
In this version, the three primary elements of the mutli-line statment are the IF..THEN statement, the optional ELSE statement, and the END IF statement. The first of these defines the conditional test, and is followed by the “true” block which is executed if the condition is true. The second optionally marks the end of the “true” block and the start of the “false” block that is executed if the condition is false. And the third of these marks the end of the multi-line statement (the end of the true or optional false blocks).
The compiler was modified for each of these statements to just emit a fake ByteCode, the _IF instruction. It has an integer operand that indicates what phase of the multi-line statement it represents from the list above. This statement is not executable (attempts to do so result in a fault). However, the linker uses these instructions as markers to patch in the correct branch instructions around the true and false blocks as needed. The linker handles nested instances of _IF blocks, and detects when they are used out of order or in a mismatched fashion.
This does mean that programming errors such as mismatched IF - END IF statements won’t be caught until link time, but that’s appropriate anyway for a language that allows you to update individual lines of code on the fly.
I’ve got more testing to do to ensure that editing a program correctly reverts the code back to _IF bytecodes, but this looks close enough to push out to the live development areas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An element of the original design of JBasic is that each statement is compiled somewhat independantly, with no knowledge of the statements that came before or after it. In fact, linking all the statements together in one large executable bytecode string (with internal branch references resolved) came along mid-way through the development.
A big advantage of this is that each statement is responsible for compiling its code and this can be cached in each statement object; only at link time are they stitched together. When a new statement is added or deleted, the individual statement(s) affected are recompiled or deleted, but the rest of the program is unaffected. A final link phase takes care of last-minute bindings.
I’ve long wanted to add a multi-line IF statement, but this violates the basic rules - such a construct would theoretically have to know about the context of other statements. But a user request for this feature got me thinking about it anew, and the solution can be much simpler than I had previously thought about.
In this version, the three primary elements of the mutli-line statment are the IF..THEN statement, the optional ELSE statement, and the END IF statement. The first of these defines the conditional test, and is followed by the “true” block which is executed if the condition is true. The second optionally marks the end of the “true” block and the start of the “false” block that is executed if the condition is false. And the third of these marks the end of the multi-line statement (the end of the true or optional false blocks).
The compiler was modified for each of these statements to just emit a fake ByteCode, the _IF instruction. It has an integer operand that indicates what phase of the multi-line statement it represents from the list above. This statement is not executable (attempts to do so result in a fault). However, the linker uses these instructions as markers to patch in the correct branch instructions around the true and false blocks as needed. The linker handles nested instances of _IF blocks, and detects when they are used out of order or in a mismatched fashion.
This does mean that programming errors such as mismatched IF - END IF statements won’t be caught until link time, but that’s appropriate anyway for a language that allows you to update individual lines of code on the fly.
I’ve got more testing to do to ensure that editing a program correctly reverts the code back to _IF bytecodes, but this looks close enough to push out to the live development areas.