,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2022-02-27 14:26:42 LSchmidt wrote: | comment - I suggest to complete the test | see: https://forth-standard.org/standard/core/POSTPONE#contribution-221 `------------------------------------------ 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. ,------------------------------------------ | 2022-02-27 18:43:57 LSchmidt wrote: | testcase - many tests appear to only assess interpretation semantics of test subjects | see: https://forth-standard.org/standard/testsuite#contribution-222 `------------------------------------------ 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? ,------------------------------------------ | 2022-02-27 20:58:46 LSchmidt wrote: | requestClarification - chasing for dangling words referred to | see: https://forth-standard.org/standard/testsuite#contribution-223 `------------------------------------------ Looking at test cases for ALLOT, I find and , 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. ,------------------------------------------ | 2022-02-27 21:23:05 LSchmidt wrote: | testcase - many tests appear to only assess interpretation semantics of test subjects | see: https://forth-standard.org/standard/testsuite#contribution-224 `------------------------------------------ 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 | `---------´ ,------------------------------------------ | 2022-02-18 14:33:12 GeraldWodni replies: | example - Forth Programmer's Handbook | see: https://forth-standard.org/standard/core/Sq#reply-788 `------------------------------------------ As discussed in the electronic interim meeting [2022i1](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z#contribution-220): We should revisit the testcase once the next snapshot is published and the testcases are re-imported into the website. ,------------------------------------------ | 2022-02-18 14:41:34 GeraldWodni replies: | example - New Line characters in a string passed to EVALUATE | see: https://forth-standard.org/standard/core/EVALUATE#reply-789 `------------------------------------------ Possible solutions discussed in the meeting [2022i](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z#contribution-220): - Handle newlines in `evaluate` - Create a new definition of `evaluate` in the `file` wordset - Create a new version of `evaluate` i.e. `multi-line-evaluate` ,------------------------------------------ | 2022-02-18 18:41:48 AntonErtl replies: | proposal - Better wording for "Glossary notation" | see: https://forth-standard.org/proposals/better-wording-for-glossary-notation-#reply-790 `------------------------------------------ At the [2022i1 meeting](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z?hideDiff#reply-787) we did not take any decisions on this proposal, but wait until the proposer and the editor are present. ,------------------------------------------ | 2022-02-18 19:03:45 AntonErtl replies: | proposal - Better wording for "data field" term | see: https://forth-standard.org/proposals/better-wording-for-data-field-term#reply-791 `------------------------------------------ At the [2022i meeting](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z?hideDiff#reply-787), 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". ,------------------------------------------ | 2022-02-18 19:07:00 AntonErtl replies: | referenceImplementation - Implement with ROT | see: https://forth-standard.org/standard/core/TwoSWAP#reply-792 `------------------------------------------ As decided at the [2022i meeting](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z?hideDiff#reply-787) : This is the version we want to put in the document. ,------------------------------------------ | 2022-02-19 16:28:44 AntonErtl replies: | proposal - Agenda Forth-200x interim Meeting 2020-02-18T14:00Z | see: https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z#reply-793 `------------------------------------------ [Meeting notes](http://www.forth200x.org/meetings/2022-02-18-notes.html) ,------------------------------------------ | 2022-02-19 19:04:45 AntonErtl replies: | proposal - Specify that 0 THROW pops the 0 | see: https://forth-standard.org/proposals/specify-that-0-throw-pops-the-0#reply-794 `------------------------------------------ ## Author: M. Anton Ertl ## Change Log: This version proposes a less minimal change, resulting after discussions at the [2022i meeting](https://forth-standard.org/proposals/agenda-forth-200x-interim-meeting-2020-02-18t14-00z#reply-787) ## 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. ,------------------------------------------ | 2022-02-21 13:33:08 ruv replies: | proposal - Specify that 0 THROW pops the 0 | see: https://forth-standard.org/proposals/specify-that-0-throw-pops-the-0#reply-795 `------------------------------------------ > 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`](https://forth-standard.org/standard/core/IF)). For execution semantics the phrase "do nothing" is used (for example, see [`[IF]`](https://forth-standard.org/standard/tools/BracketIF)[1]). So a better wording is: > If all bits of _n_ are zero, remove _n_ from the stack and do nothing more. ----- [1] For [`[IF]`](https://forth-standard.org/standard/tools/BracketIF) 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](https://forth-standard.org/standard/notation#subsubsection.2.2.4.2); a stack diagram is a normative part of a semantic description). ,------------------------------------------ | 2022-02-21 14:32:04 ruv replies: | proposal - Better wording for "data field" term | see: https://forth-standard.org/proposals/better-wording-for-data-field-term#reply-796 `------------------------------------------ > 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](https://forth-standard.org/standard/usage#subsubsection.3.3.3.2) ("a region of data space..."), [A.3.3.3.2 Contiguous regions](https://forth-standard.org/standard/rationale#paragraph.A.3.3.3.2) ("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. ,------------------------------------------ | 2022-02-22 12:28:19 flaagel replies: | comment - There is an error in testing | see: https://forth-standard.org/standard/core/WHILE#reply-797 `------------------------------------------ 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. ,------------------------------------------ | 2022-02-28 14:17:40 LSchmidt replies: | comment - "(" typo in a testcase | see: https://forth-standard.org/standard/core/p#reply-798 `------------------------------------------ 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 ... ,------------------------------------------ | 2022-02-28 14:52:55 ruv replies: | testcase - many tests appear to only assess interpretation semantics of test subjects | see: https://forth-standard.org/standard/testsuite#reply-799 `------------------------------------------ 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](https://github.com/gerryjackson/forth2012-test-suite) repository. ,------------------------------------------ | 2022-02-28 16:06:39 ruv replies: | comment - I suggest to complete the test | see: https://forth-standard.org/standard/core/POSTPONE#reply-800 `------------------------------------------ > 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](https://forth-standard.org/standard/testsuite#test:core:POSTPONE ) So, a definition missed in the place can be found somewhere above.