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


,------------------------------------------
| 2023-03-06 00:03:30  ruv  wrote:
| proposal - Update rationale for SLITERAL
| see: https://forth-standard.org/proposals/update-rationale-for-sliteral#contribution-292
`------------------------------------------
## Author

Ruv

## Change Log

- 2023-03-06 Initial version

## Problem

In the [draft 2020-01](https://github.com/Forth-Standard/forth-standard/blob/6e4d1083c06e8e326b53f29072570fe510b58aec/forth.pdf), the section A.17.6.1.2212 `SLITERAL` conflicts with the section 6.1.2165 `S"`. 

In 2017 it was decided to merge the words FILE `S"` and `S\"` into the corresponding words in CORE/CORE-EXT (see the [minutes 2017](https://github.com/Forth-Standard/forth200x/blob/master/meetings/2017-notes#L92) and preceding discussion "[Core-ext `S\"` should reference File-ext `S\"`](https://forth-standard.org/proposals/core-ext-s-should-reference-file-ext-s-)"). It was implemented in the draft 2020-01.

However, the section A.17.6.1.2212 has not been updated, and it shows an implementation for CORE `S"` before 2017, which leads to confusions (it was noticed by Anthony Howe in "[Confusion over `S"` and `SLITERAL`](https://github.com/ForthHub/discussion/discussions/128)").

## Solution

Update the section A.17.6.1.2212 according to the new 6.1.2165. Take into account  [A.6.1.0190 `."`](https://forth-standard.org/standard/rationale#rat:core:.q).


## Proposal

Replace the content of the section [A.17.6.1.2212 `SLITERAL`](https://forth-standard.org/standard/rationale#rat:string:SLITERAL) by the following:

> The current functionality of 6.1.2165 `S"` may be provided by the following definition:
> ```
> : S" ( "ccc<quote>" -- c-addr u | )
>     [CHAR] " PARSE STATE @ IF POSTPONE SLITERAL THEN
> ; IMMEDIATE
> ```
> Note: Depending on the Forth system implementation, this definition may leads to the following environmental restrictions:
>   - the lifetime of the string returned by the interpretation semantics for `S"` is only valid until the input buffer is refilled or the input source is changed;
>   - the compilation semantics for `S"` that are appended by applying `POSTPONE` to `S"` cannot be performed if the system in interpretation state.

In the section 6.1.2165 `S"`, add into the last paragraph, which starts with "See:", at the end before the dot:
> , A.17.6.1.2212 `SLITERAL`



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


,------------------------------------------
| 2023-03-03 07:04:18  JohanKotlinski  replies:
| proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT
| see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-999
`------------------------------------------
SAVE-INPUT/RESTORE-INPUT are used in some user-space code, for example in Gforth assemblers + cross-compilers. Example:

```
: .times{  ( n -- input n )
  dup >r 1 > IF  save-input  THEN  r> ;
: .}times  ( input n -- input n-1 / 1 / )
  1- dup 0>
  IF  >r restore-input throw r@ 1 >
      IF  save-input  THEN  r>
  THEN ;
:D
```

I can only imagine one workaround, which is to copy input to a buffer, and `EXECUTE` it from there. Obviously, such a workaround increases CPU+RAM usage.


,------------------------------------------
| 2023-03-04 20:37:49  ruv  replies:
| proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT
| see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-1000
`------------------------------------------
> `SAVE-INPUT`/`RESTORE-INPUT` are used in some user-space code, for example in Gforth assemblers + cross-compilers. 

It's a good finding.
The words `.times{` and `.}times` are formally defined in the standard Forth. Although, as I can see, they are not used anywhere.

One problem with this construct is that it can work or fail without any explanation, — since the standard does not guarantee any conditions in which `restore-input` shall work. So the construct `.times{ ... .}times` is actually a system-specific means (or it has an environmental dependency concerning behavior of `restore-input`).

Another problem with this construct is that the body is performed at least once regardless of _n_.
To correctly implement the case of _n_=0,  we need to parse the input stream till the corresponding closing `.}times` (with possible nesting).
But if we parse the input stream in this way, we can save the extracted text into a buffer and just translate (evaluate) it the given number of times, without employing `save-input`/`restore-input`.

I believe, we should have an API that helps in such tasks. Under the hood it can save a content or position (depending on the input source kind), and provides a uniform interface. Actually, such an API can be even implemented in a portable way if we standardize two things:
1. When the input stream is a string, the line comment shall skip up to the nearest line terminator or to the end of the input buffer (what is encountered first) (see a [comment](https://forth-standard.org/standard/core/EVALUATE#reply-789)).
2. A program should not depend on the input source kind from which it's translated. It means, it should not rely that the input buffer contains a single line, and that `refill` reads a single line (see [Portable line-oriented parsing](https://github.com/ForthHub/discussion/discussions/126)). Probably, some helper words should be standardized for that.

> Obviously, such a workaround increases CPU+RAM usage.

It depends on how `save-input` is implemented. A reliable implementation can also save a fragment of the input stream into the memory. OTOH, repeating reading from the file can take more CPU than reading from memory.