Digest #165 2021-09-12
Contributions
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
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.
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).
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.
same answer as with the GT-1 question:
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.
requestClarification - Implementation for «S"» via the immediacy mechanism
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)
The committee endorses ruv's answer. closed.
comment - Note incompatability (double v single) with some older Forth's.
Closing because this comment has been answered.
The committee discussed this and decided to take no action.
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.
This comment has been answered. Closing.
This comment has been answered. Closing.
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.
In my comment 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?
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.
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.
referenceImplementation - Portable implementation for SYNONYM
On behalf of the committee: As decided in this reply:
The implementation of SYNONYM requires detailed knowledge of the host implementation, which is why it [the word, not a reference implementation] is standardized.
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.
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.
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.
The question has been answered.
comment - How to avoid default compilation semantics in the specification for [COMPILE]
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.
comment - THROW: text doesn't match implementation example
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.