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


,------------------------------------------
| 2019-08-05 17:25:38  flaagel  wrote:
| referenceImplementation - GNU C RESTRICT would make sense in the standard
| see: https://forth-standard.org/standard/core#contribution-104
`------------------------------------------
IMMEDIATE sets the corresponding flag in the latest compiled word header.
GNU Forth RESTRICT sets the compile-only flag in a similar manner. I think
it should be standardized for the sake of completeness.



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


,------------------------------------------
| 2019-08-05 07:13:43  AntonErtl  replies:
| requestClarification - Test example numeric base?
| see: https://forth-standard.org/standard/core/BL#reply-273
`------------------------------------------
Hayes' [core.fr](http://git.savannah.gnu.org/cgit/gforth.git/tree/test/coretest.fs) starts with HEX.  Now that we have standardized number prefixes, we could use number prefixes (e.g., $20) to eliminate this dependence on BASE.


,------------------------------------------
| 2019-08-05 15:55:56  ruv  replies:
| requestClarification - Test example numeric base?
| see: https://forth-standard.org/standard/core/BL#reply-274
`------------------------------------------
I think, regardless other third party files, numbers in the specification should be in decimal by default. The [test suit](https://forth-standard.org/standard/testsuite#subsection.F.2.3) from Annex F restores BASE after loading.

Also, in other places the decimal radix is implied. E.g. the tests for [+LOOP](https://forth-standard.org/standard/core/PlusLOOP). 



,------------------------------------------
| 2019-08-06 09:28:24  ruv  replies:
| referenceImplementation - GNU C RESTRICT would make sense in the standard
| see: https://forth-standard.org/standard/core#reply-275
`------------------------------------------
`restrict` in Gforth is synonym for [compile-only](https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Interpretation-and-Compilation-Semantics.html). Its behavior is described as "Remove the interpretation semantics of a word". Such behavior description cannot take place in the standard.

By the standard, if a word with undefined interpretation semantics is encountered by the text interpreter in interpretation state the occurring behavior is implementation specific. A possible variant is to even perform its compilation semantics. There is no much sense for a standard program to transform the well defined interpretation semantics of some word to something unknown, that will be depend on implementation.