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


,------------------------------------------
| 2017-10-25 11:16:43  AntonErtl  wrote:
| example - Bug in 3.4.1.3
| see: https://forth-standard.org/standard/usage#contribution-33
`------------------------------------------
As pointed out by Harold <hzrabbie@gmail.com>, "printable character" is not defined in the standard, and there are definitions (Wikipedia) that include BL among the printable characters.  However, in the '<char>' syntax, <char> was not intended to be BL; moreover, ' ' produces the xt of ' on all tested systems (as intended).  So we should fix this bug by replacing

   <char> represents any printable character.

 by

  <char> represents any non-blank non-control character.


,------------------------------------------
| 2017-10-25 11:35:46  AntonErtl  wrote:
| proposal - BL rationale is wrong
| see: https://forth-standard.org/proposals/bl-rationale-is-wrong#contribution-34
`------------------------------------------
Both Forth-2012 and Forth-94 specify ASCII as character encoding, so we know that the value of BL is #32 (or $20).  The rationale claims that BL is the only way to get this value, but it is wrong.


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


,------------------------------------------
| 2017-09-08 09:07:15  LeonWagner  replies:
| proposal - The value of STATE should be restored
| see: https://forth-standard.org/proposals/the-value-of-state-should-be-restored#reply-87
`------------------------------------------
What is your use case for this? Could you show us an example?


,------------------------------------------
| 2017-09-08 11:48:24  AntonErtl  replies:
| proposal - The value of STATE should be restored
| see: https://forth-standard.org/proposals/the-value-of-state-should-be-restored#reply-88
`------------------------------------------
We discussed this at the standards meeting, but do not have an answer for this proposal yet.  Anyway, here is my personal answer:

It is a common problem to have a global variable that you want to restore on exiting a word, whether the exit is regular, or through THROW.  This problem exists not just for system variables like STATE or BASE, but also for application variables.  The general approach that I recommend is to have wrappers around the code that changes the variables.  The wrapper catches any exception coming through, restores the old value of the variable, and then THROWs the exception (if any) on.  For STATE, this can be done as follows:

```
: state! ( f -- )
  if ] else postpone [ then ;
: state-wrapper ( xt -- )
  state @ >r catch r> state! throw ;

\ usage example
s" ] non-existent-word" ' evaluate ' state-wrapper catch .
```


,------------------------------------------
| 2017-09-25 14:04:02  AlexDyachenko  replies:
| proposal - The value of STATE should be restored
| see: https://forth-standard.org/proposals/the-value-of-state-should-be-restored#reply-89
`------------------------------------------
My main use case was trying to handle any errors that may occur when including another file, e.g.
```
S" somefile.4th" ' INCLUDED CATCH ...
```
This code could be interpreted or compiled, and of course inside somefile.4th the STATE can change arbitrarily prior to a THROW.  So anything following CATCH would only work as intended if STATE had not changed.  Your example is certainly one way to work around this, but it requires every use of CATCH to be wrapped.  In my opinion, if CATCH does not restore STATE, it falls short of satisfying this from the THROW Rationale: "If THROW is executed with a non zero argument, the effect is as if the corresponding CATCH had returned it."  The application variables are certainly the application's responsibility, but system variables should be the system's.

If an otherwise standard system chose to restore STATE and BASE as part of the CATCH semantics, would this still be a standard system?


,------------------------------------------
| 2017-10-25 13:15:11  BerndPaysan  replies:
| proposal - BL rationale is wrong
| see: https://forth-standard.org/proposals/bl-rationale-is-wrong#reply-90
`------------------------------------------
Indeed, so we could move BL to core ext to make it optional.

There's no need for a size constrained system to contain a word that's trivially replaced by a literal with known value.