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


,------------------------------------------
| 2026-07-19 22:11:19  AbstractionFirst  wrote:
| comment - BASE exposes representation rather than abstraction
| see: https://forth-standard.org/standard/core/BASE#contribution-438
`------------------------------------------
The Forth standard has gradually moved away from exposing implementation mechanisms to standard programs. Words such as `TIB`, `#TIB`, `QUERY`, `EXPECT`, `SPAN`, and `CONVERT` were removed because they exposed implementation details rather than language-level abstractions.

`BASE` exposes a storage representation rather than the abstraction that portable programs actually require.

A standard program accesses the current radix through:

```
BASE @
BASE !
```

This does more than specify observable behavior. It also requires `BASE` to behave as the address of a cell.

Conceptually, however, the current radix is part of the language state rather than an ordinary user variable. A program needs to observe and modify its value, but it should not depend on how that value is represented internally.

One possible direction would be to model `BASE` as a `VALUE`, allowing:

```
BASE
16 TO BASE
```

This preserves the programmer's intent while eliminating an unnecessary level of indirection and leaving the underlying representation entirely implementation-defined.


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


,------------------------------------------
| 2026-07-19 16:05:44  ruv  replies:
| comment - A language standard should specify abstractions rather than mechanisms
| see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-1689
`------------------------------------------
We have a [proposal](https://forth-standard.org/proposals/obsolescence-for-save-input-and-restore-input#contribution-291) to make the words `save-input` and `restore-input` obsolescent.

In any case, these words are **optional** and may be absent in a standard Forth system.

-----

> to specify **observable semantics**

Yes, sure. Note that in some cases, to observe semantics (behavior), we have to execute not just one word, but several words or even a program.

> They expose and preserve the internal state of the input-processing mechanism rather than providing an application-level abstraction.

They do not expose internal state. They produce and consume an opaque data object and allow to **restore** internal state (withing specified constraints), without exposing its internal details. Beyond these operations, the user is only allowed to store and fetch this data object from memory.

Conceptually, these words could replace the functionality of [`>in`](https://forth-standard.org/standard/core/toIN). However, this did not happen because they are much less convenient to use.

I think the problem with these words isn't that they are not abstract enough, but that:
  - they don't provide sufficient guarantees (they might work with one input source kind but not another),
  - their flag of success is inverted,
  - they are not suitable for solving practical problems.