[437] 2026-07-18 19:38:23 AbstractionFirst wrote:

comment - A language standard should specify abstractions rather than mechanisms

I would like to raise a more general design question rather than the specific semantics of SAVE-INPUT itself.

One of the primary goals of a language standard is to specify observable semantics while leaving implementation details to implementors whenever possible.

This raises the following question:

Can a portable application express a requirement that naturally maps to SAVE-INPUT?

In practice, application programs manipulate data, define new words, parse text, compile code, evaluate strings, and process files. They naturally use words such as PARSE, EVALUATE, REFILL, and POSTPONE.

SAVE-INPUT and RESTORE-INPUTappear to belong to a different category. They expose and preserve the internal state of the input-processing mechanism rather than providing an application-level abstraction.

If these words are intended primarily for implementors of Forth systems rather than for portable application programs, should they really be part of the standard application interface?

More generally, should a language standard expose implementation mechanisms, or should it specify only the observable behavior required of a conforming system?

I believe this distinction deserves discussion because it directly affects implementation freedom without changing observable language semantics.