[438] 2026-07-19 22:11:19 AbstractionFirst wrote:

comment - BASE exposes representation rather than abstraction

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.

[r1689] 2026-07-19 16:05:44 ruv replies:

comment - A language standard should specify abstractions rather than mechanisms

We have a proposal 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. 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.