Digest #212 2023-02-19
By my reading, the phrase
DUP 0= XOR INVERT should transform the flag returned by
ENVIRONMENT? into a false flag, regardless of what it started as. The first test case (querying "X:deferred") is thus guaranteed to fail.
I spent some time coming up with a testcase that I thought was sure to be useful, but then I read the specification here and at 3.2.6 Environmental queries more carefully. There appears to be nothing that prevents a standard-compliant system from simply responding false, "unknown", to all queries; the only restriction is that an attribute cannot cease to be known (and cannot change once known, if it is specified to be constant). With that in mind,
ENVIRONMENT? is well and truly untestable.
Given the complete lack of words for transferring floating-point numbers between the data stack and the floating-point stack, a float recognised by the interpreter as per subsection 12.3.7 is presumably placed on the floating-point stack, if it exists. This is eminently reasonable and understandable, but it might be helpful to make it explicit: lacking any indication to the contrary, I naively assumed that such a float would be placed on the data stack and spent a bit of time looking for a word that would move it to the FP stack.
Ah! Now I understand what you were saying. It was not immediately clear to me that
j*x could mean
nr-sys, or that the rationale was saying that just pushing
nr-sys was not an option. I read the statement to mean that it was an option. I definitely think that:
( x<sup>n ... x<sup>1 +n -- ) ( R: -- nr-sys +n )
would be a much clearer stack notation, for what it's worth. It also feels like there should be some mention of an ambiguous condition if n<0.
Confirmed: The X:deferred test case is wrong.
And yes, the lack of guarantees from ENVIRONMENT? means that writing discerning test cases for ENVIRONMENT? is a problem. What is possible is to write test cases that test the result if the environmental query succeeds.