Digest #252 2024-01-22
Is the PAD buffer guaranteed to be aligned (in the sense of ALIGNED)? This section, and section 126.96.36.199, 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.
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).
You can avoid the prompt by using
abort. Likewise, you can exit from a deeply nested
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 under
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