Digest #278 2024-08-14
Contributions
It turns out that in some implementations to behaves incorrectly when its argument is an immediate word.
t{ 0 value vfoo immediate -> }t
t{ : change-vfoo 1 to vfoo ; -> }t
t{ vfoo change-vfoo vfoo -> 0 1 }t
(hopefully, we will automatically render source codes in uppercase later)
Replies
requestClarification - Behavior of EMPTY-BUFFERS when BLK is nonzero
When BLK is non-zero you might be running code from blocks. There is absolutely no reason to prevent your code from essentially marking all your buffers as unused. Unlike some other reputable members of the Forth community, I do make a difference between blocks and buffers. I like to associate a state to each buffer. It is an 'enum' value of sorts:
- UNUSED: there is no established mapping between the buffer and a block.
- MAPPED: a mapping between a block and a buffer has been set up (via a call to BLOCK or LOAD).
- DIRTY: a mapping has been established and the buffer is marked for update to mass storage.
EMPTY-BUFFERS just disables the mapping between buffers and blocks (without flushing them to mass storage).
requestClarification - Behavior of EMPTY-BUFFERS when BLK is nonzero
When
BLKis non-zero you might be running code from blocks.
Yes.
There is absolutely no reason to prevent your code from essentially marking all your buffers as unused.
Yes. But the specification should say whether this action is allowed (and what its effects) or not (and effects are unspecified). See also the original question on ForthHub.
A better wording for this ambiguous condition is:
An ambiguous condition exists if
EMPTY-BUFFERSis executed whenBLKcontains a non-zero value.
And on the next iteration an exception should be used (to eliminate this ambiguous condition).
EMPTY-BUFFERSjust disables the mapping between buffers and blocks
This is allowed. Also, it is allowed to free the memory of buffers.