,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2023-02-16 07:07:08  AidanPitt-Brooke  wrote:
| testcase - First testcase broken
| see: https://forth-standard.org/standard/core/ENVIRONMENTq#contribution-284
`------------------------------------------
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](https://forth-standard.org/standard/usage#usage:env) 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.


,------------------------------------------
| 2023-02-17 02:48:38  AidanPitt-Brooke  wrote:
| requestClarification - Location of floats parsed from source
| see: https://forth-standard.org/standard/float#contribution-285
`------------------------------------------
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](https://forth-standard.org/standard/float#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.


,---------.
| Replies |
`---------´


,------------------------------------------
| 2023-02-18 03:40:16  JimPeterson  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-971
`------------------------------------------
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</sup> ... x<sup>1</sup> +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.


,------------------------------------------
| 2023-02-18 12:03:26  AntonErtl  replies:
| testcase - First testcase broken
| see: https://forth-standard.org/standard/core/ENVIRONMENTq#reply-972
`------------------------------------------
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.