POKE and PEEK prohibited on the same line?
There is no such restriction in any somewhat standard BASIC, as it would go against how BASIC works. Lines function only to handle source during editing, and to allow walking them at runtime for sequence and serve as
GOSUB targets. They do not form any construct of execution bracket.
Any language doing so would not be BASIC (*1).
Execution in BASIC rather simple and straightforward:
- Lines are executed in sequence.
- Statements in a line are executed in sequence.
POKE is a statement. It will be executed when parsed without any relations to prior (*2,3) or later statements, or any expressions within.
- Any statement executed may have parameters.
- All parameters will be evaluated in sequence left to right.
- Parameters may be (and usually are) expressions.
PEEK is a function.
- Functions can be used as (part of) an expression.
Thus when in a program like:
10 FOR I = 768 to 783
20 POKE I, PEEK(I+1)
30 NEXT I
40 POKE 784, 0
20 is executed,
- Evaluate the first parameter
I as the target.
- Evaluation returns the content of
- Evaluate the second parameter as the value.
- Doing so includes calling the function
I+1 as its target.
- Fetches the content of that location.
- Returns whatever that is.
POKE will use both (target, value) to store value at target.
As a result that program will move all bytes from
0300h..030Eh (*4). What else :)
there is one somewhat known exceptional version of PEEK in TI Extended BASIC. TI BASIC did not implement any PEEK or POKE function or command, as the concept of that machine is more advanced than your average home computer, allowing a closer integration (*5). With Extended BASIC
PEEKwas added in form of
CALL PEEK(<addr>, var [,var[,...]])
It was meant for speedy access binary data, loaded via
CALL LOAD or some other means, for further use - such as sprite images or sound. As mentioned, TI BASIC was quite advanced, but thus 'special' as well.
*1 - I have a hard time finding any reason to implement such.
*2 - Of course statements may be conditioned by an
*3 - Statements following a
GOTO on the same line (and
REM statements) will of course not be executed.
*4 - Yes, it's a 16-byte queue walking one step closer. :))
*5 - Machine programs could be loaded using
CALL LOAD(<name>,<code>), which not only handled the usual DATA-read-loops, but also linked the result into BASIC (*6). Invocation with
CALL LINK(<function>, <var>...) allowed exchange via standard BASIC variables, so no need to PEEK and POKE around. Just call it.
*6 - Which makes it quite different from a POKE or multi byte POKE of other implementations.