,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-09-11 12:25:15 AntonErtl wrote: | proposal - Specify that 0 THROW pops the 0 | see: https://forth-standard.org/proposals/specify-that-0-throw-pops-the-0#contribution-213 `------------------------------------------ __Hint: Please delete the blockquote explanations, they are just for your convenience while writing the proposal__ ## Author: M. Anton Ertl ## Change Log: First version ## Problem: The specification of THROW does not say that it pops the 0 on 0 THROW ## Solution: The following is a minimal fix. If somebody is willing to give THROW a more substantial rework, go ahead ## Typical use: (Optional) ``` ... search-wordlist 0= -13 and throw execute ``` ## Proposal: Behind the stack effect of 9.6.1.2275 THROW, insert > Remove n from the stack. ,---------. | Replies | `---------´ ,------------------------------------------ | 2021-09-09 08:42:32 AntonErtl replies: | proposal - PLACE +PLACE | see: https://forth-standard.org/proposals/place-place#reply-746 `------------------------------------------ The specification requires a specific (and probably not useful) behaviour when the start of the target address is in [c-addr1, caddr1+u). The reference implementation uses MOVE, which guarantees a different (and probably more useful) behaviour in that case. The two should be reconciled, and in this case I think it's better to change the specification to agree with the (more useful) reference implementation. For +PLACE there is the additional complication of whether the original or updated count should be copied if it is in [c-addr1,c-addr1+u), but at least in this case the specification and the implementation agree that the updated count is copied; Gforth also behaves that way, but SwiftForth's APPEND updates the count only afterwards. ,------------------------------------------ | 2021-09-09 11:06:55 AntonErtl replies: | proposal - PLACE +PLACE | see: https://forth-standard.org/proposals/place-place#reply-747 `------------------------------------------ Also, for PLACE, the specification specifies that the count byte is stored first, while the reference implementation, the Gforth implementation and the SwiftForth implementation store it afterwards. This makes a difference if c-addr2 is in [c-addr1,c-addr1+u). ,------------------------------------------ | 2021-09-09 13:44:53 GeraldWodni replies: | requestClarification - GT1 not defined | see: https://forth-standard.org/standard/core/POSTPONE#reply-748 `------------------------------------------ The committee discussed that issue: It would blow up the testcases if we add all required test-words for every word making the document too big. We could do this on the website itself though: the best solution would be to write a forth program which finds all required references and updates the test definitions for the words. However this is a lot of work. If you are interested, we would welcome a pull request for this feature on the [forth-standard.org repository](https://github.com/GeraldWodni/forth-standard.org/). ,------------------------------------------ | 2021-09-09 13:46:33 GeraldWodni replies: | requestClarification - write-cell-mem undefined | see: https://forth-standard.org/standard/memory/ALLOCATE#reply-749 `------------------------------------------ _same answer as with the [GT-1 question](https://forth-standard.org/standard/core/POSTPONE#reply-748):_ The committee discussed that issue: It would blow up the testcases if we add all required test-words for every word making the document too big. We could do this on the website itself though: the best solution would be to write a forth program which finds all required references and updates the test definitions for the words. However this is a lot of work. If you are interested, we would welcome a pull request for this feature on the [forth-standard.org repository](https://github.com/GeraldWodni/forth-standard.org/). ,------------------------------------------ | 2021-09-09 14:11:18 ruv replies: | requestClarification - Implementation for «S"» via the immediacy mechanism | see: https://forth-standard.org/standard/file/Sq#reply-750 `------------------------------------------ > The original 94 TC very likely meant this (state-smart `S"`) to be standard, but failed to specify it that way. Does this answer imply that my implementation has conflict with the **normative parts** of the Forth-94 standard? If yes, could you please show such a conflict? (I reopen this request since my question still remains) ,------------------------------------------ | 2021-09-09 14:12:06 UlrichHoffmann replies: | comment - Throwing past DO/LOOP | see: https://forth-standard.org/standard/exception/THROW#reply-751 `------------------------------------------ The committee endorses ruv's answer. closed. ,------------------------------------------ | 2021-09-09 14:13:40 AntonErtl replies: | comment - Note incompatability (double v single) with some older Forth's. | see: https://forth-standard.org/standard/core/num#reply-752 `------------------------------------------ Closing because this comment has been answered. ,------------------------------------------ | 2021-09-09 14:25:25 StephenPelc replies: | comment - Cells numeration in a cell-pair | see: https://forth-standard.org/standard/core/TwoStore#reply-753 `------------------------------------------ The committee discussed this and decided to take no action. ,------------------------------------------ | 2021-09-09 14:40:18 UlrichHoffmann replies: | comment - Query re status; and minor comments | see: https://forth-standard.org/proposals/multi-tasking-proposal#reply-754 `------------------------------------------ On behalf of the committee we invite you to pick up the proposal and develop it further. As you seem quite interested in the standard you are welcome to attend the next meeting. ,------------------------------------------ | 2021-09-09 14:42:52 AntonErtl replies: | comment - Data type for strings | see: https://forth-standard.org/standard/usage#reply-755 `------------------------------------------ This comment has been answered. Closing. ,------------------------------------------ | 2021-09-09 14:51:39 AntonErtl replies: | example - Relationship to block set | see: https://forth-standard.org/standard/core/SOURCE#reply-756 `------------------------------------------ This comment has been answered. Closing. ,------------------------------------------ | 2021-09-09 16:15:06 ruv replies: | proposal - Tick and undefined execution semantics - 2 | see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics-2#reply-757 `------------------------------------------ > attempting to __obtain__ the execution token > attempting to **use** the execution token This change destandardizes implementations where a word like `IF` cannot be found in interpretation state and `' IF` throws an exception in such case. ,------------------------------------------ | 2021-09-09 16:24:16 ruv replies: | proposal - Reword the term "execution token" | see: https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-758 `------------------------------------------ In my [comment](https://forth-standard.org/proposals/reword-the-term-execution-token-#reply-570) I showed that we don't have a problem that was pointed out. If we don't have counter arguments on that, why do we need this change at all? ,------------------------------------------ | 2021-09-09 21:10:24 AntonErtl replies: | proposal - Tick and undefined execution semantics - 2 | see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics-2#reply-759 `------------------------------------------ Two hours of wordsmithing with PK, HO, and ruv resulted in: In the glossary entries 6.1.0070 ' (Tick) and 6.1.2510 ['] (BracketTick) replace the phrase: > An ambiguous condition exists if name is not found. by > Throw -13 if name is not found. and append: > If name has no execution semantics or no interpretation semantics, performing the semantics identified by the xt is ambiguous. In the glossary entries 6.2.2295 TO, 6.2.1725 IS, 6.2.0698 ACTION-OF, replace the phrase: > An ambiguous condition exists if any of POSTPONE, [COMPILE], ' or ['] are applied to TO. by the phrase: > An ambiguous condition exists if POSTPONE or [COMPILE] are applied to TO. In the section 4.1.2 Ambiguous conditions replace the phrase: > attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc. of a definition with undefined interpretation semantics; by the phrase > a word does not have both interpretation and execution semantics, ', FIND or SEARCH-WORDLIST return an xt for that word, and the semantics identified by that xt are performed. We should examine all the words that have not both interpretation and execution semantics for possible unintended consequences. ,------------------------------------------ | 2021-09-10 07:57:06 AntonErtl replies: | proposal - Tick and undefined execution semantics - 2 | see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics-2#reply-760 `------------------------------------------ One problem with the proposal (both the original and the wordsmithed version) is that the following is ambiguous: ``` synonym my+ + 1 2 ' my+ execute ``` The reason is that SYNONYM defines only interpretation and compilation semantics of MY+, not the execution semantics, so this ambiguous condition would strike. My suggestion at fixing this is: * Instead of covering both interpretation and execution semantics in the ambiguous condition, cover just interpretation semantics and S" S\" TO IS ACTION-OF. * ' ['] FIND SEARCH-WORDLIST return an xt identifying the interpretation semantics. I think that this is the right way to go because there are no words with defined execution semantics and different defined interpretation semantics. Basically, they are the same, and the only reason why we have them as separate concepts in the standard is that we have some words (e.g., >R) where we define the compilation semantics through execution semantics, but where we undefine the interpretation semantics. An alternative would be to define such words with compilation semantics and run-time semantics (i.e., without execution semantics), and replace "interpretation semantics" with "execution semantics" in the rest of the document. ,------------------------------------------ | 2021-09-11 08:02:18 AntonErtl replies: | referenceImplementation - Portable implementation for SYNONYM | see: https://forth-standard.org/standard/tools/SYNONYM#reply-761 `------------------------------------------ On behalf of the committee: As decided in [this reply](https://forth-standard.org/standard/tools/SYNONYM?hideDiff#reply-554): > The implementation of SYNONYM requires detailed knowledge of the host implementation, which is why it [the word, not a reference implementation] is standardized. ,------------------------------------------ | 2021-09-11 11:05:05 AntonErtl replies: | testcase - More general Testcase | see: https://forth-standard.org/standard/core/DEPTH#reply-762 `------------------------------------------ The original Hayes tester assumed that each test case was called with an empty stack (and did not work as intended when it was not). One of the improvements of the ttester (T{ ... }T) was that it would also work if a test starts with a non-empty stack. Of course for Hayes' test cases for DEPTH, the test cases themselves require that the test case is invoked with an empty stack. There is no standard way to test that DEPTH returns the absolute depth. Both suggested approaches for testing whether DEPTH works correctly for relative depths are ok; the latter approach is preferable because understanding it does not require intimate knowledge of the testing framework. Thank you both. ,------------------------------------------ | 2021-09-11 11:27:05 AntonErtl replies: | testcase - Inaccurate Test Cases? | see: https://forth-standard.org/standard/double/DtoS#reply-763 `------------------------------------------ On behalf of the committee: Since we have decided to standardize 2s-complement arithmetic, the test case is correct for the next standard. We are not going to correct this test case for Forth-2012. In the unlikely case that someone wants to write a Forth-2012 system for a sign-magnitude or 1s-complement system, the present discussion should give enough warning that these test cases will not work for them. ,------------------------------------------ | 2021-09-11 11:35:15 AntonErtl replies: | testcase - Additional test for UTF-16 | see: https://forth-standard.org/standard/core/CComma#reply-764 `------------------------------------------ This is a good test case that tests the (standardized) relation between characters as processed with C, C@ C!, and ASCII characters in a string (processed with S" and COMPARE). ASCII characters are guaranteed to consume only one char in memory, only extended characters may consume more than one char in their memory representation. ,------------------------------------------ | 2021-09-11 11:47:00 AntonErtl replies: | example - Needs an example of replacing COMPILE | see: https://forth-standard.org/standard/core/POSTPONE#reply-765 `------------------------------------------ The question has been answered. ,------------------------------------------ | 2021-09-11 12:04:39 AntonErtl replies: | comment - How to avoid default compilation semantics in the specification for [COMPILE] | see: https://forth-standard.org/standard/core/BracketCOMPILE#reply-766 `------------------------------------------ The implementation of [COMPILE] needs to know how EXIT is implemented, the user does not need to know. As you point out elsewhere, a number of systems get [COMPILE] EXIT wrong; and apparently users don't care enough to report this bug to the maintainer of the affected systems. One reason is probably that, if they want the standard behaviour of [COMPILE] EXIT, they just write EXIT. In any case, [COMPILE] is obsolescent, so the behaviour of [COMPILE] will probably be outside of the scope of the next standard; therefore the appetite in the committee for discussing it is very small. ,------------------------------------------ | 2021-09-11 12:29:27 AntonErtl replies: | comment - THROW: text doesn't match implementation example | see: https://forth-standard.org/standard/exception/THROW#reply-767 `------------------------------------------ The text starts with > If any bits of n are non-zero, and later it says > If the top of the stack is non zero [...] Admittedly it does not say anything about what happens if n=0, but that generally means that it does nothing. However, what it does in that case is to pop n; this is reflected in the stack effect ( k * x n -- k * x ) for that case, but the specification does not say that this stack effect refers to this case, so I have [proposed to make it clear that n is popped](proposals/specify-that-0-throw-pops-the-0#contribution-213).