6.2.2182 SAVE-INPUT CORE EXT

Again, where have you tested the code?

RESTORE-INPUT changes the input source state, so after the next REFILL the parse area contains not " NeverExecuted" but " siv @" (that returns 0 in this time).

Hello ruv,

I do apologize for the noise. Back when I published this, I was focusing on implementing EVALUATE without having a clearly defined SAVE-INPUT and RESTORE-INPUT process. The smoke has cleared up from my side since then and I have learned my lesson. I should always compare behaviour to what GNU Forth does, even though I will never support all the features of that beats.

Sorry about that.

    Francois

Umm... given that N>R R>N are listed as related. Is the intended workflow like this?

SAVE-INPUT N>R ... R>N RESTORE-INPUT ?

I would prefer if it was allowed to keep the state on some other stack.

Probably, you need other (system-specific) words for that. The words save-input and restore-input are not what they appear on the first glance — see my other comment.

Is the intended workflow like this? SAVE-INPUT N>R ... R>N RESTORE-INPUT ?

It's a possible workflow, but in a single found program that uses these words ("Lambda Expressions in ANS Forth" by Gerry Jackson), they are used in a totally different manner. See a discussion on ForthHub.

Yes, it's a requirement. However, given that the other requirements (guarantees to programs) are very weak, you do not need to put a lot of data on the data stack (at least for a minimal implementation of SAVE-INPUT).

Those who support N>R NR> told me that SAVE-INPUT N>R ... NR> RESTORE-INPUT is a usage that motivates N>R NR>. WHERE N>R on SwiftForth shows two uses, both after SAVE-INPUT and likewise both usese of NR> are before RESTORE-INPUT.

N>R on SwiftForth shows two uses, both after SAVE-INPUT and likewise both usese of NR> are before RESTORE-INPUT.

BTW, in SwiftForth RESTORE-INPUT is used on a different input source. A standard program cannot use them in such a manner due to an ambiguous condition, which "exists if the input source represented by the arguments is not the same as the current input source".

Also, a SwiftForth version 3.11.6 peculiar (probably not only its) is that RESTORE-INPUT returns 0 (success) when it actually does not restore the state of the input source — e.g., in the case of keyboard. In this case it restores the position, but not the content of the input buffer. According to the specification, it shall restore nothing and return fail (-1), if it cannot restore the state of the input source.

In my opinion, the ctual SAVE-INPUT values could be in a different memory area at some addrese ADDR and the stack effect of SAVE-INPUT might just be ( -- ADDR 1 ). This would be acceptable as a standard behaviour and would relieve the data stack on stack space limited systems.

We discussed this question at the meeting on 2023-02-17, and our conclusion was that we do not recommend implementing SAVE-INPUT and RESTORE-INPUT on systems that are so memory constrained that the amount of data-stack memory is a problem.

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.

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

Given the lack of guarantees in restore-input, probably not. If restore-input was specified more tightly, yes. The usage would be a multi-line variant of what >in is used for (judging from the rationale).

My impression is that nobody uses save-input and restore-input in code that is intended to be portable, though. And while there are occasional questions about what these words are good for, nobody has actually pushed for a tightening of the specification.

My guess is that if these words are removed from the standard, no one who intends to write a standard program will miss them.

If these words are intended primarily for implementors of Forth systems rather than for portable application programs

Reading the rationale, the intention was to provide a feature for portable application programs. My dim memory of some of the discussions about these words is that some people have pointed out that some systems use them to implement some other words, such as IIRC included.

These words do not expose implementation mechanisms. I can think of many implementation approaches that support useful implementations of these words, and none that are incompatible with useful implementations of these words. And useless implementations do not care about the implementation of the input stream at all.

I think my original point was not expressed clearly enough.

My intention was not to discuss whether SAVE-INPUT is useful, whether it should be specified more tightly, or how it can be implemented.

The question I was trying to raise is a different one:

Should facilities that manipulate the interpreter's own state belong to the application interface at all?

In other words, my concern is not the design of SAVE-INPUT itself, but the criteria used to decide whether such words belong in the standard programming interface for portable applications.

Should facilities that manipulate the interpreter's own state belong to the application interface at all?

Your point was that save-input and restore-input are not in the same category as parse and refill. I didn't see any criteria by which these categories are distinguished. All of these words manipulate the state of the Forth system, namely, the state of the input source (in contrast, evaluate does not affect the state of the input source). Changing the value at >in also manipulates the state of the input source, as does its potential replacement, the word set-source-offset.

The Forth standard, at its core, defines an interface to the Forth system (an API). See 1.2 Scope, which says: "This standard specifies an interface between a Forth System and a Forth Program by defining the words provided by a Standard System". It's impossible to remove all words that affect the state of the Forth system.

The distinction I am proposing is not based on whether a word manipulates the state of the Forth system.

It is about the language model.

The current standard mixes together words that are primarily needed by Forth implementors with words that are intended for general application programming.

My point is about the architecture of the language as a whole rather than the implementation of individual words.

My point is about the architecture of the language as a whole rather than the implementation of individual words.

You should probably present your ideas as a new proposal with specific changes, rather than as comments on individual words.

Should facilities that manipulate the interpreter's own state belong to the application interface at all?

I generally recommend to not write parsing words, but writing them is common practice, and until we have made the alternatives (such as recognizers or passing strings) compelling enough that people rewrite their code in terms of the alternatives, there is common practice, and the standard should include words for writing them.

The current standard mixes together words that are primarily needed by Forth implementors with words that are intended for general application programming.

There is no need to standardize words that are not useful outside the Forth system, and AFAICS, no such words have been standardized, certainly not those that you mentioned in your recent comments. These words are all intended for portable Forth programs; some people may consider not all of these programs to be "general application programs", but it's unclear what the criteria would be for this distinction.

About the question in the title " A language standard should specify abstractions rather than mechanisms" , even when I agree with the sentence a fundamental question arise in my brain: is this sentence compatible with the philosophy of Forth itself? as far as I know Forth has always been a language that do not hide implementation to the user and developer, it focuses in simplicity and hardware aware design , so I feel walking the path of abstraction is walking the opposite way of Forth pathway , even when I agree Forth classification of world into words is a powerful kind of abstraction

is this sentence compatible with the philosophy of Forth itself?

That depends on what you mean with "the philosophy of Forth"? If you mean Chuck Moore's philosophy, standardization itself is not compatible with it, so he has bowed out of the standardization process many decades ago.

You can examine individual ideas that have been claimed to be part of the philosophy of Forth for compatibility with this sentence, but I think that it is a better use of your time to examine how well individual words or word groups satisfy goals like ease of use, ease of implementation, efficiency, portability between hardware platforms, portability between Forth systems, etc. I think that the Forth-94 committee generally did a good job in providing abstractions that satisfy many of these goals, with some exceptions.