Digest #173 2022-03-01
Contributions
add a word : GT1 123 ; as first line.
Currently it is necessary to extrapolate from context that a non-immediate word with that name and semantics is required.
testcase - many tests appear to only assess interpretation semantics of test subjects
Tests may be incomplete when only looking at the interpret time semantics. Many Forth systems don't simply compile a call to the same code portion of a tested word. Instead, they may generate code which may be different and unrelated to the executed code during interpretation.
Shouldn't those tests therefore not also test against a word which the testee has been compiled to?
requestClarification - chasing for dangling words referred to
Looking at test cases for ALLOT, I find <TRUE> and <FALSE>, those defined elsewhere in terms of 0S and 1S. Hunting for those, I find a reference in F.3.2 Booleans, saying:
To test the booleans it is first neccessary to test F.6.1.0720 AND, and F.6.1.1720 INVERT. Before moving on to > the test F.6.1.0950 CONSTANT. The latter defines two constants (0S and 1S) which will be used in the further > test.
No, it doesn't. it tests the 0S INVERT case to match 1S, and the 1S INVERT case for 0S. Seems that tester is free to come up with his own idea of how to represent 0S and 1S.
testcase - many tests appear to only assess interpretation semantics of test subjects
Tests may be incomplete when only looking at the interpret time semantics. Many Forth systems don't simply compile a call to the same code portion of a tested word. Instead, they may generate code which may be different and unrelated to the executed code during interpretation.
Shouldn't those tests therefore not also test against a word which the testee has been compiled to?
Replies
As discussed in the electronic interim meeting 2022i1: We should revisit the testcase once the next snapshot is published and the testcases are re-imported into the website.
example - New Line characters in a string passed to EVALUATE
Possible solutions discussed in the meeting 2022i:
- Handle newlines in
evaluate - Create a new definition of
evaluatein thefilewordset - Create a new version of
evaluatei.e.multi-line-evaluate
At the 2022i1 meeting we did not take any decisions on this proposal, but wait until the proposer and the editor are present.
At the 2022i meeting, we discussed the issue:
Mentioning CREATE is correct for the current state of the standard document, and helps the reader understand the limitations of the term "data field"; if the standard is changed such that other types of words can have data fields, we can change the the definition of this term at this time.
Concerning "The data space": This is qualified by the following text, so the meaning is clear to us at the meeting. However, if a clarification is wanted, it could be replaced with "The portion of data space" or "The part of data space".
As decided at the 2022i meeting : This is the version we want to put in the document.
proposal - Agenda Forth-200x interim Meeting 2020-02-18T14:00Z
Author:
M. Anton Ertl
Change Log:
This version proposes a less minimal change, resulting after discussions at the 2022i meeting
Problem:
The specification of THROW does not say what happens on 0 THROW
Solution
This is still a pretty minimal change. A more subtantial rework would move the input stream handling elsewhere in the standard (this has come up as a cause for confusion). Moreover, I think the organization of the various cases is suboptimal. A better approach might be
- n=0
- n!=0
- exception stack non-empty
- exception stack empty
- n=-1
- n=-2
- otherwise
If you want (or don't want) such changes, reply to this proposal.
Typical use: (Optional)
... search-wordlist 0= -13 and throw execute
Proposal:
Behind the stack effect of 9.6.1.2275 THROW, insert
If all bits of n are zero, remove n from the stack and continue execution behind the THROW.
If all bits of n are zero, remove n from the stack and continue execution behind the THROW.
The phrase "continue execution" is used in descriptions of run-time semantics only (for example, see IF).
For execution semantics the phrase "do nothing" is used (for example, see [IF][<sup>1]).
So a better wording is:
If all bits of n are zero, remove n from the stack and do nothing more.
[<sup>1] For [IF] it could also say "remove flag from the stack", since otherwise it looks like a mismatch of the stack diagram and the text of the semantic description (see also 2.2.4.2 Glossary semantic description; a stack diagram is a normative part of a semantic description).
Concerning "The data space": This is qualified by the following text, so the meaning is clear to us at the meeting.
By what following text? The definition says only the following:
data field: The data space associated with a word defined via CREATE.
If you mean some following section, a term definition should not rely on them, I think. The term definitions and notations constitute a bedrock on which other parts are grounded. It's like axioms on which theorems are grounded.
However, if a clarification is wanted, it could be replaced with "The portion of data space" or "The part of data space".
The phrases "portion of data space", "part of data space", "data space region" are synonyms. A difference is that the later one is already used in other parts of the standard, but the two former are not. For example, see 3.3.3.2 Contiguous regions ("a region of data space..."), A.3.3.3.2 Contiguous regions ("The data space of a Forth system comes in discontiguous regions").
Probably, somebody can mean "a region of the data space" by "a data space", but it's better to avoid such looseness in a normative text.
This is a tricky implementation point. Z79Forth also choked on this particular piece of the test suite. Not that it is really a problem since my primary allegiance is 79-STANDARD but I still believe that ANS compliance, whenever achievable, is desirable. This is now fixed and I will release the updated code on GitHub soon.
Seems that nobody cares - it's also still wrong in https://forth-standard.org/standard/testsuite#F.6.1.0080 and a bit of a nuisance when bitten by tests failing when basing those on the provided test cases.
I was first contemplating the possible reasons for making ( state smart in this bizarre way ...
testcase - many tests appear to only assess interpretation semantics of test subjects
I think, this Test Suite was not intended to cover 100% of possible use cases.
In any case, additional tests can be also directly suggested into the forth2012-test-suite repository.
add a word
: GT1 123 ;as first line.
The testcase fragments of code are automatically generated from the full test suite. And some words are reused in many places. And it's not easily to automatically detect and include such words in the fragment.
Probably the problem can be mitigated by adding a link to the full testcase, in this case: https://forth-standard.org/standard/testsuite#test:core:POSTPONE So, a definition missed in the place can be found somewhere above.