Digest #252 2024-01-22
Contributions
Is the PAD buffer guaranteed to be aligned (in the sense of ALIGNED)? This section, and section 3.3.3.6, do not say.
If PAD is not necessarily aligned then it is very tempting to just make it an alias on HERE; but users of PAD must then mind alignment issues, at least on systems where unaligned accesses are undesirable. I don't know whether PAD should be mandated to be aligned or not, but I think that alignment guarantees or lack thereof should be documented somewhere.
Replies
There is no alignment guarantee for PAD.
The traditional implementation (e.g., fig-Forth) has PAD at some distance from HERE: In traditional systems WORD copies the data to HERE, then there is the pictured numeric output buffer, and then there is PAD. The pictured numeric output buffer grows downwards from PAD-1. So the distance between HERE and PAD in those systems accomodates the size of the pictured numeric output buffer and maybe the strings scanned by WORD (if the system wants to support using <#...#> while parsing with WORD).
example - "make the user input device the input source"
You can avoid the prompt by using abort. Likewise, you can exit from a deeply nested include/eval with abort (but I have never had the need).
After sealing the search order with MY-LANG-WID 1 SET-ORDER, you do not need to quit, just return to the text interpreter normally (which also allows you to load the DSL and then continue with the program written in the DSL in an included file, without the user having to use some including word interactively after loading the DSL.
Conceptually the problem was that those "virtual"
EVALUATE's (and "virtual"INCLUDE's for file CLI args) should also run underQUIT
Why? They don't run under quit in Gforth, but before it, if quit is run at all (in development Gforth it isn't). It seems to me like you are thinking that there is a requirement to use quit somewhere; there isn't. If the system is easier to implement without calling quit, don't call quit.