Skip to content

Reporting of Forth Characteristics #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
steverpalmer opened this issue Nov 18, 2015 · 5 comments
Open

Reporting of Forth Characteristics #2

steverpalmer opened this issue Nov 18, 2015 · 5 comments

Comments

@steverpalmer
Copy link
Collaborator

While running the tests, certain Implementation-defined characteristics of the Forth system may be derived, such as the number of bits in a cell. It would be nice if these derived characteristics of the Forth system could be reported along with the test results. (This is a similar to the behaviour of the floating point Paranoia - http://www.netlib.org/paranoia/.)

@steverpalmer
Copy link
Collaborator Author

For example, when running the tests, included in the details are the lines:

YOU SHOULD SEE THE NUMBER RANGES OF SIGNED AND UNSIGNED NUMBERS:
  SIGNED: -8000000000000000 7FFFFFFFFFFFFFFF 
UNSIGNED: 0 FFFFFFFFFFFFFFFF 

This is potentially valuable information, but could be easily missed in amongst the other output. It would be nicer if there was a separate section in the output, perhaps near the Error Report at the end where this information could be collected and displayed.

@gerryjackson
Copy link
Owner

Good idea. We need to define what characteristics could be reported. Number ranges are obvious as are bits/cell and au's/char. We could report results from environment queries which are otherwise untested. Let's get the next release of the test suite sorted out first.

@steverpalmer
Copy link
Collaborator Author

I agree that this is not an urgent issue, but perhaps this "issue" could be used to catch any ideas we have about characteristic reporting.

One other idea that I had was that the test suite could also list words that are supplied but are considered obsolete, such as #TIB, CONVERT, EXPECT, QUERY, SPAN, TIB, etc. This may be particularly relevant if these words are not tested.

@gerryjackson
Copy link
Owner

I deliberately didn't include words marked obsolescent in the original test programs as I hadn't included them in my system. Nobody complained. In Forth 2012 [COMPILE] was designated obsolescent so I removed any tests on that - Stephen Pelc of MPE had complained when his system failed and suggested using POSTPONE instead which would have been a curious way of testing [COMPILE] :) I'm open to having tests on obsolete words but would suggest they went in a separate test program.

@gerryjackson
Copy link
Owner

Issue #18 suggests another item that could be reported, the behaviour of ALIGN and ALIGNED.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants