,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2024-01-20 20:26:44  ThomasPornin  wrote:
| requestClarification - PAD alignment
| see: https://forth-standard.org/standard/core/PAD#contribution-332
`------------------------------------------
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 |
`---------´


,------------------------------------------
| 2024-01-21 17:27:03  AntonErtl  replies:
| requestClarification - PAD alignment
| see: https://forth-standard.org/standard/core/PAD#reply-1171
`------------------------------------------
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).


,------------------------------------------
| 2024-01-21 18:28:35  AntonErtl  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1172
`------------------------------------------
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 under `QUIT`

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`.