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


,------------------------------------------
| 2023-03-02 19:04:49  ruv  wrote:
| proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT
| see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#contribution-291
`------------------------------------------
## Author

Ruv

## Change Log

- 2023-03-02 Initial version

## Problem

The words [`SAVE-INPUT`](https://forth-standard.org/standard/core/SAVE-INPUT) and [`RESTORE-INPUT`](https://forth-standard.org/standard/core/RESTORE-INPUT) almost don't bear any usefulness to programs, and they only burden implementers.

These words have the following problems:
- Too few guarantees to programs: `RESTORE-INPUT` may work or fail depending on on the input source kind (file, pipe, string, keyboard).
- The returned flag of `RESTORE-INPUT` is inconsistent with other words: *true* means fail, *false* means success. A better variant could be a throwable *ior*.
- In some systems `RESTORE-INPUT` works [incorrectly](https://forth-standard.org/standard/core/SAVE-INPUT#reply-959) in some cases: it restores the position in the input buffer and returns success, but doesn't restore the content of the input buffer.


These words are almost not used in programs. I asked in [comp.lang.forth](https://groups.google.com/g/comp.lang.forth/c/AqQrQ4rx6rI/) and [ForthHub](https://github.com/ForthHub/discussion/discussions/134). Only one program was mentioned: "Lambda Expressions in ANS Forth" by Gerry Jackson ([sources](http://qlikz.org/forth/archive/lambda.zip)), and in this case the problem can be also solved without these words.

What is sometimes required in programs is an ability to parse (extract) a text fragment from the input stream, and later translate (evaluate) this fragment in the current context, **regardless** whether the input stream was switched or not. Such an API should be designed separately. The words `SAVE-INPUT` and `RESTORE-INPUT` cannot help on that.


## Solution

Declare the words `SAVE-INPUT` and `RESTORE-INPUT`as obsolescent, to destandardize (remove from the standard) them on the next iteration.

## Consequences

This change doesn't affect the standard systems. The new (or updated) standard systems can be made slightly simpler by not providing an implementation and documentation for these words (if they are not used internally).

The standard programs that employ these words gain a new environmental dependency, and later they become non compliant to the new versions of the standard.
 
## Proposal

In the section [1.4.2 Obsolescent features](https://forth-standard.org/standard/intro#subsection.1.4.2), 
after the phrase "This standard designates the following word as obsolescent:", add:

> - 6.2.2182 SAVE-INPUT
> - 6.2.2148 RESTORE-INPUT
 

In each of the glossary entries [6.2.2182 `SAVE-INPUT`](https://forth-standard.org/standard/core/SAVE-INPUT) and [6.2.2148 `RESTORE-INPUT`](https://forth-standard.org/standard/core/RESTORE-INPUT) add the following **note**:

> #### Note:
> This word is obsolescent and is included as a concession to existing implementations. 





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


,------------------------------------------
| 2023-02-25 12:12:57  flaagel  replies:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/double/DZeroEqual#reply-992
`------------------------------------------
or, more simply:

: D0= OR 0= ;



,------------------------------------------
| 2023-02-26 18:05:37  JimPeterson  replies:
| referenceImplementation - Possible Reference Implementation
| see: https://forth-standard.org/standard/double/DZeroEqual#reply-993
`------------------------------------------
... oh, yes.  What was I thinking?


,------------------------------------------
| 2023-02-26 18:44:30  ruv  replies:
| example - Stack Sizes?
| see: https://forth-standard.org/proposals/multi-tasking-proposal#reply-994
`------------------------------------------
In the general case a stack cannot be replaced by a new one (of more size), since addresses in the stack can be used under the hood.

What is possible (for each stack, or at least the data stack and return stack) are:
  - to ask the system for a number of available cells in the stack (similar to `unused` for data space);
  - to execute a definition with guaranteed amount of the stack space (so a new stack can be allocated before execution, and freed after; in the case of the data stack the parameters should be passed to the new stack and the results — to the old one);
  - to specify the stack size for a new thread (before creating/starting);
  - to specify the stack size for the Forth system before starting;


See also a StackOverflow question: [Set stack size programmatically on Windows](https://stackoverflow.com/questions/45258017/set-stack-size-programmatically-on-windows).



,------------------------------------------
| 2023-02-26 20:30:02  ruv  replies:
| requestClarification - The specification of CATCH 
| see: https://forth-standard.org/standard/exception/CATCH#reply-995
`------------------------------------------
> In GerryJackson's example, [...] `CATCH` transfers control back to the interpreter

Yes.
I think, "a point just after `CATCH`" should be interpreted not as a point in the source code, but as a point in run-time that is performed just after performing `catch` if `throw` was not performed (so it's the same point regardless whether `throw` was performed or not).

For example in the phrase "`['] catch execute .`" (which is a part of a definition) a point after performing `catch` is the point after `execute` in this source code.

When `catch` is encountered by the Forth text interpreter in interpretation state, a point just after performing `catch` is a point after `execute` inside the Forth text interpreter. And when this `execute` returns, the Forth text interpreter continues to parse the input source according its current state.

>  without restoring the parse area to its original state because that's not a reasonable thing to require. 

Yes. And formally it must not restore this state, because restoring of this state is [not specified](https://forth-standard.org/standard/exception/THROW#contribution-283).



,------------------------------------------
| 2023-03-02 17:33:03  ruv  replies:
| referenceImplementation - Example implementation for PICK
| see: https://forth-standard.org/standard/core/PICK#reply-996
`------------------------------------------
```
: pick ( x_u ... x_1 x_0 u -- x_u ... x_1 x_0 x_u )
  dup 0= if drop dup exit then  swap >r 1- recurse r> swap
;
```
(the stack diagram is copied from the glossary entry)



,------------------------------------------
| 2023-03-02 17:37:13  ruv  replies:
| referenceImplementation - Example implementation for PICK
| see: https://forth-standard.org/standard/core/PICK#reply-997
`------------------------------------------
```
: pick ( x_u ... x_1 x_0 u -- x_u ... x_1 x_0 x_u )
  dup 0= if drop dup exit then  swap >r 1- recurse r> swap
;
```
(the stack diagram is copied from the glossary entry)



,------------------------------------------
| 2023-03-02 19:10:24  ruv  replies:
| referenceImplementation - Example implementation for ROLL
| see: https://forth-standard.org/standard/core/ROLL#reply-998
`------------------------------------------
```
: roll ( x_u x_u-1 ... x_0 u -- x_u-1 ... x_0 x_u )
  dup 0= if drop exit then  swap >r 1- recurse r> swap
;
```
(the stack diagram is copied from the glossary entry)