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


,------------------------------------------
| 2023-11-27 18:02:20  AntonErtl  wrote:
| requestClarification - WORD and the text interpreter
| see: https://forth-standard.org/standard/core/WORD#contribution-315
`------------------------------------------
In traditional implementations, the text interpreter uses WORD and thus clobbers the buffer used by word.  This can be seen with the following test:

```
: ctype count type ; cr bl word uno ctype
```

If the text interpreter does not clobber the word buffer, this test outputs "uno"; if the text interpreter uses the WORD buffer, it outputs "ctype".  Here are the results for different Forth systems:

```
output system
uno    Gforth 0.7.3, Copyright (C) 1995-2008 ...
ctype  iForth-5.1-mini
uno    lxf 1.6-982-823 Compiled on 2017-12-03
ctype  SwiftForth x64-Linux 4.0.0-RC52 20-Sep-2022
uno    VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
```

So two systems clobber the WORD buffer in the text interpreter (as is traditional).

The reason for this request is that I fail to find any hint in the standard that the WORD buffer may be clobbered by parsing by the text interpreter.  An obvious place would be 3.3.3.6, and it does mention certain circumstances when the contents of the WORD buffer may become invalid, but these circumstances do not include parsing by the text interpreter.  A not so good place would be 3.4.1, but I don't find any such a provision there, either.  If the standard contains such a provision, it is well hidden and that should be fixed.

If the standard does not contain such a provision, there are two options:

1. Fix the systems to avoid clobbering the WORD buffer in the text interpreter
2. Change the standard to allow clobbering the word buffer by parsing in the text interpreter.

Given that I have seen confused questions by users over the clobbering behaviour by some systems several times, I would prefer option 1.  If you prefer option 2, make a proposal for such a change.



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


,------------------------------------------
| 2023-11-13 20:26:44  albert  replies:
| proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT
| see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-1135
`------------------------------------------
I don't understand what this proposal has to do with "interpreted loops" . All noforths and ciforths (Dutch Forths) have interpreted loops with using SAVE-INPUT and RESTORE-INPUT.


,------------------------------------------
| 2023-11-13 20:27:07  albert  replies:
| proposal - Obsolescence for SAVE-INPUT and RESTORE-INPUT
| see: https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#reply-1136
`------------------------------------------
I don't understand what this proposal has to do with "interpreted loops" . All noforths and ciforths (Dutch Forths) have interpreted loops without using SAVE-INPUT and RESTORE-INPUT.


,------------------------------------------
| 2023-11-13 22:17:45  ruv  replies:
| proposal - String store and fetch
| see: https://forth-standard.org/proposals/string-store-and-fetch#reply-1137
`------------------------------------------
Some [arguments](https://forth-standard.org/proposals/place-place?hideDiff#reply-924) against `PLACE` and `+PLACE` are applicable to this proposal too.

1. The words `{string}!`, `{string}+!`, and `{string}C+`  are bad practice since they don't check the size of the result buffer.
A better stack effect for such words is `( c-addr.string u.string  c-addr.buf u.buf -- )`, and throw an exception of overflow.

2. there is no need to include these words in the standard if they [can be provided](https://forth-standard.org/proposals/place-place?hideDiff#reply-1134) as a portable library.