You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specification of NAME>INTERPRET in section 15.6.2.1909.20 of the Forth 2012 standard document includes "If nt has no interpretation semantics, NAME>INTERPRET returns 0."
Following a discussion on comp.lang.forth there seems to be a move to permitting words such as IF that have no interpretation semantics to be ticked. This leads to NAME>INTERPRET returning a valid xt even if that xt does something nonsensical - indeed GForth has been modified recently to do just this and so fails the current test.
This means that it is difficult if not impossible to find a standard word without interpretation semantics where NAME>INTERPRET will return 0. There is a suggestion to have a configuration file for the test suite so I propose to leave the test on NAME>INTERPRET as it is and include an option in a future configuration file where the user would specify a suitable word that returns 0 or that that particular test should be by-passed.
Any comments?
The text was updated successfully, but these errors were encountered:
I wrote the previous message months ago and forgot about it. As GForth has defined interpretation semantics for all words that don't have defined interpretation semantics I've changed the test so that it tries all such words in the Core word set to see if 0 is returned, If none of them do it simply displays a message stating that. It may be better to place that in the configuration file to save the user having to think about it.
The specification of NAME>INTERPRET in section 15.6.2.1909.20 of the Forth 2012 standard document includes "If nt has no interpretation semantics, NAME>INTERPRET returns 0."
Following a discussion on comp.lang.forth there seems to be a move to permitting words such as IF that have no interpretation semantics to be ticked. This leads to NAME>INTERPRET returning a valid xt even if that xt does something nonsensical - indeed GForth has been modified recently to do just this and so fails the current test.
This means that it is difficult if not impossible to find a standard word without interpretation semantics where NAME>INTERPRET will return 0. There is a suggestion to have a configuration file for the test suite so I propose to leave the test on NAME>INTERPRET as it is and include an option in a future configuration file where the user would specify a suitable word that returns 0 or that that particular test should be by-passed.
Any comments?
The text was updated successfully, but these errors were encountered: