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


,------------------------------------------
| 2024-01-24 09:35:34  AntonErtl  wrote:
| comment - In the list of contributions and replies by a person, please link to the contribution or reply
| see: https://forth-standard.org/meta-discussion#contribution-333
`------------------------------------------
When I look at, e.g. [my contributions and replies](https://forth-standard.org/~AntonErtl), all the links only point to the page, not to the specific contribution or reply.  On some pages, there have been quite a number of contributions and replies, and there it is hard to find the particular one from the list.

Also the list of contributions and replies could be ordered with the most recent first, as is common on the rest of this site, and there could be a link from the start to the start of the replies (useful for frequent contributors).


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


,------------------------------------------
| 2024-01-22 09:56:20  AntonErtl  replies:
| requestClarification - loopsys in data?
| see: https://forth-standard.org/standard/core/DO#reply-1173
`------------------------------------------
Such an implementation would be standard.

Conceptually system-internal data generated during compilation is not part of data space even if it is interleaved with data space data (at least parts of the standard handle it this way; not sure if the standard is consistent here).


,------------------------------------------
| 2024-01-24 00:40:57  lmr  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1174
`------------------------------------------
> 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).

That's actually ("quit(e)" ?) interesting and perhaps merits a separate discussion. So we could try
```
: "ABORT" S" ABORT" ;
: "QUIT"  S" QUIT" ;
: weird EVALUATE ." done" CR ;
: tst ['] weird CATCH ." caught: " . CR ;
"ABORT" tst
"QUIT" tst
```

The first `tst` should print "caught", -1, and leave [ -1 <garbage> ] on the stack.

I think that under the current letter of the standard, the second `tst` should hand control back to the user device while leaving an exception frame on the stack (I don't see anything in the spec about `QUIT` clearing the exception stack). The text interpreter then behaves normally, until the user causes a throw (for example by typing `XXX`; there is no other way to exit `QUIT`, although that would also be interesting). Then the `CATCH` would come into effect.

However the implementations I've tried seem to clear the exception stack upon `QUIT`, so maybe I'm misreading something, or maybe the standard isn't clear.


,------------------------------------------
| 2024-01-24 09:49:36  AntonErtl  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1175
`------------------------------------------
As described in 9.3.3, the exception stack may be on the return stack.  I am sure that the intent of the committee was that anything (including `quit`) that removes stuff from the return stack also removes the stuff from the exception stack and correspondingly sets the pointer to the current exception frame.  This should be fixed in the document (see also [r1148](https://forth-standard.org/standard/core/QUIT#reply-1148)).


,------------------------------------------
| 2024-01-24 11:51:39  lmr  replies:
| example - "make the user input device the input source"
| see: https://forth-standard.org/standard/core/QUIT#reply-1176
`------------------------------------------
OK. Maybe there should be an explicit paragraph or something about which stacks have return-stack semantics and which ones have data-stack semantics (i.e. not cleared on `QUIT`). As another point I've just realized that `TRAVERSE-WORDLIST` can't use the control stack to save a working copy of the list of name-tokens in the wid as a higher-level data structure (the control stack already presupposes structured items, so it's tempting to abuse it, depending on implementation details). So far I've seen:
* control stack: data stack semantics
* N>R stack: return stack semantics
* exception stack: return stack semantics
* input source stack: return stack semantics (?)