[264] 2022-09-06 14:26:04 flaagel wrote:

testcase - Incorrect Test Pattern

It should be:

T{ SOURCE-ID DUP -1 = SWAP 0= OR -> <TRUE> }T

[265] 2022-09-06 14:36:57 flaagel wrote:

testcase - Bogus Test Case for SAVE-INPUT

In the "Testing" NeverExecuted obviously is executed and that's the end of it!

[r859] 2022-08-29 05:46:02 ruv replies:

requestClarification - Should QUIT propagate exceptions?

because there is no exception stack in CORE.

Actually no, since the behavior of QUIT could be updated in the Exception word set. It looks like just an omission.

---

Concerning the throw code -56 that you mention on github, I don't think it has anything to do with the Forth word QUIT. My guess is that it's for the Unix signal SIGQUIT

1. Then it should be named "SIGQUIT". It would be confused to call it "QUIT" when you have a word having name "QUIT".

2. Then some hint to POSIX signals should be given.

3. Then throw codes should be assigned to other signals too.

So SIGQUIT version doesn't look quite convinced to me.

[r860] 2022-08-29 09:47:45 flaagel replies:

testcase - >NUMBER Test Patterns

Problem solved. core.fr is supposed to be run in HEX. I was running the >NUMBER test cases interactively after doubletest.fth had switched BASE to DECIMAL.

[r861] 2022-08-30 11:09:46 ruv replies:

proposal - Exclude zero from the data types that are identifiers

According to FILE SOURCE-ID, fileid cannot be -1 too.

So relationship for fileid should be: fileid => x \ {0,-1}

[r862] 2022-08-30 12:06:09 ruv replies:

proposal - Exclude zero from the data types that are identifiers

Probably it makes sense to use simpler wording as:

Extend "3.1.1 Data-type relationships" by the following

instead of

Add the following to the end of the list of subtype relationships in the section 3.1.1 Data-type relationships

[r863] 2022-08-30 12:16:35 ruv replies:

proposal - Exclude zero from the data types that are identifiers

Should the notation {0} be also described?

Actually, this notation is already described in 2.2.1 Numeric notation. Probably it should be extended to the case of explicit items enumeration as { number [, number ]* }, e.g. {0}, {-1,0,1}.