Digest #251 2024-01-09
Contributions
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
example - "make the user input device the input source"
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.
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).