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


,------------------------------------------
| 2024-01-08 06:17:40  lmr  wrote:
| requestClarification - loopsys in data?
| see: https://forth-standard.org/standard/core/DO#contribution-331
`------------------------------------------
Would it be conforming for an implementation to generate a new loopsys in *data* space for every `DO` ever compiled (and keep track of which loopsys is current during compilation, for example using the control or return stack)? This would of course (permanently) waste data space, compared to the "normal" way of (temporarily) consuming return-stack space.


,---------.
| Replies |
`---------´


,------------------------------------------
| 2024-01-07 22:38:40  AntonErtl  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1169
`------------------------------------------
OS command-line processing is outside the scope of the standard, so the standard is silent on these issues.

Gforth uses `evaluate` to process the `-e` arguments; and actually `-e` is a shorthand for `--evaluate`.

Concerning `quit`, in a system with the exception wordset there is little reason for programs to call `quit`.  `quit` is generally used for implementing the startup of a system, or the recovery from an uncaught `throw`, but one does not need to standardize it to use it as an internal system word.  It seems like a no-longer useful legacy word to me.


,------------------------------------------
| 2024-01-08 05:43:00  lmr  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1170
`------------------------------------------
> there is little reason for programs to call quit

It can be (mis-?) used to avoid displaying the prompt, to exit from a deeply nested include / eval... or when writing an interpreter / DSL in Forth, one can call `MY-LANG-WID 1 SET-ORDER QUIT` as a final step — then let `QUIT` handle the new language. But I suppose there is also `ABORT`, `THROW` / `CATCH` etc

> Gforth uses evaluate to process the -e arguments; and actually -e is a shorthand for --evaluate.

Maybe I spent too much time thinking about this. Conceptually the problem was that those "virtual" `EVALUATE`'s (and "virtual" `INCLUDE`'s for file CLI args) should also run under `QUIT`, and `QUIT` cannot be run multiple times since it doesn't relinquish control (except to the HOST OS); so how does `QUIT` know about them? My hack was to start `QUIT` with a "cooked" input source, above stdin in the logical input stack, that contains all those virtual calls (plus a call to`." blah blah"` to print the greeting).