Digest #64 2019-07-11
Contributions
Why does an ambiguous condition exist if [IF] is POSTPONEd? And why does not it spread to[ELSE]?
What can be wrong with:
: [UNLESS] 0= POSTPONE [IF] ; IMMEDIATE
Replies
The code is standard.
Images are not standardized, so what a system does on image creation and restoration is up to the system.
I think that it would be too restrictive to not support this kind of code (at least if FOO was an address in the dictionary), so systems will support it in some way, either by always restoring the image to the same addresses, or by supporting relocatable images.
E.g., Gforth supports relocatable images, so even though the address of FOO may change across image saving and restoring, BAR will work as intended. Some not so common uses do not work across image saving and restoring, though, e.g., if you compute a hash value from data that includes an address.
All the new names with : at the end were introduced because the corresponding names without colon already have a conflicting meaning in a widely used system. I know this for sure for the field words and for {:, for BUFFER: I don't remember any discussion about the name.
PARSE-NAME was originally proposed as PARSE-WORD, but that name has conflicting behaviour in some widely-used systems, so PARSE-NAME was chosen.
While consistency in naming conventions is desirable, and it would be nice if no name existed that might be considered to belong to a different group of words than it actually belongs to, that seems too high a standard to satisfy in all cases. And in particular, I don't think the benefits of this principle are worth the cost that renaming existing standard words would entail.
Good catch. IMHO it is entirely sensible that children of BUFFER: may return different addresses on different runs. Apart from Anton's example, consider a buffer allocated from the heap. Heap allocation may vary from run to run.
At the time (early 1990s) it was expected that BLOCK and friends would slowly die away. Especially with the rise of retro-computing BLOCK and friends remain healthy.
When PARSE-NAME was chosen (2005) the definitions from the first group (2012) was not proposed yet. So this inconsistency did not exist in those time (and I did not have any objection for PARSE-NAME name too). It has appeared far later.
Perhaps in the future some kind of namespaces will be introduced in Forth to distinguish the groups of words. But for now we should choose names more carefully. I suppose that inconsistency in naming confuses the newbies and gives the impression of a bad designed programming language. So I would like to make Forth Standard better.
I agree that we can't just rename the already existing standard words. But we can add the synonyms with better names, and leave the old variants for back compatibility.
[IF] ... [ELSE] ... [THEN] can be nested, in which case subsequent [IF]s all paste to a matching [THEN].
Consider what happens when [UNLESS] is placed within an [IF] ... [THEN] block.