POKE and PEEK prohibited on the same line?
No ...
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 GOTO
/ 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
line 20
is executed, POKE
will:
- Evaluate the first parameter
I
as the target.
- Evaluation returns the content of
I
.
- Evaluate the second parameter as the value.
- Doing so includes calling the function
PEEK
, which:
- Evaluates
I+1
as its target.
- Fetches the content of that location.
- Returns whatever that is.
- Then
POKE
will use both (target, value) to store value at target.
As a result that program will move all bytes from 0301h..030Fh
to 0300h..030Eh
(*4). What else :)
... But
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 PEEK
was 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 IF
/ THEN
clause.
*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.