Digest #253 2024-01-25


[333] 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

When I look at, e.g. my contributions and replies, 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).


[r1173] 2024-01-22 09:56:20 AntonErtl replies:

requestClarification - loopsys in data?

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

[r1174] 2024-01-24 00:40:57 lmr replies:

example - "make the user input device the input source"

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

: "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.

[r1175] 2024-01-24 09:49:36 AntonErtl replies:

example - "make the user input device the input source"

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

[r1176] 2024-01-24 11:51:39 lmr replies:

example - "make the user input device the input source"

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 (?)