Use of SAVE-INPUT and RESTORE-INPUT

[Ruvim]

It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.

They are like FILE-POSITION and REPOSITION-FILE, but they work for the
current input source.

Did anybody use them in programs/libraries? (not in system internals)

I can only imagine their application in an interpretive loops
implementation.


--
Ruvim

[Marcel Hendrix]

I didn't find anything in SwiftForth and Vfx. The below is cute, but
rather pointless as such (by Wil Baden or Neil Bawd?).

-marcel

-- --------------
ANEW -rt

NEEDS -ran-next

\ *******************************************************************
\ * *
\ * Linear Congruential Sequence *
\ * *
\ * A linear congruential sequence (LCS) depends on four magic *
\ * numbers: X[0], M, A, and C. *
\ * *
\ * 0 VALUE X[i] X[0] TO X[i] *
\ * : RAND ( -- u ) X[i] A * C + M MOD dup TO X[i] ; *
\ * *
\ *******************************************************************

\ *********** Assorted Simple Random Number Generators ************

0 VALUE SEEDi
0 VALUE X[i]
0 VALUE Y[i]

: RANDOM-std ( -- u ) X[i] $107465 * $234567 + dup TO X[i] ;

: RANDOM2P ( -- u )
RANDOM-std #255 AND #24 LSHIFT
RANDOM-std #255 AND #16 LSHIFT OR
RANDOM-std #255 AND 8 LSHIFT OR
RANDOM-std #255 AND OR ;

: Random-Aphwb ( -- u ) X[i] #69069 * 1+ dup TO X[i] ;

\ Estimated cycle: about 74 quadrillion.

: Rand-Next2 ( -- 1..2147483647 )
X[i]
#48271 #2147483647 */MOD DROP
dup TO X[i]
Y[i]
#40692 #2147483399 */MOD DROP
dup TO Y[i]
- dup 0> NOT IF #2147483647 + ENDIF ;

\ **************************** Timing *****************************

VARIABLE TOOL TOOL OFF SAVE-INPUT TOOL @ [IF]

#1000000000 to #TIMES
\ ?Forth iForth; Athlon
SEEDi TO X[i] [TIME Random-Aphwb DROP TIME] \ 5 secs 1.8 secs
SEEDi TO X[i] [TIME RANDOM-std DROP TIME] \ 5 secs 1.6 secs
SEEDi TO X[i] [TIME RANDOM2P DROP TIME] \ 31 secs 5.6 secs
SEEDi TO X[i] 1 TO Y[I] [TIME Rand-Next2 DROP TIME] \ 66 secs 13.8 secs
SEEDi Ran-Start [TIME Ran-Next DROP TIME] \ 99 secs 22.9 secs

[ELSE]

: ANNOUNCE >IN @ >R BL <WORD> CR TYPE Tab EMIT R> >IN ! ;
: :GO S" MARKER NONCE : (GO) " EVALUATE ; IMMEDIATE
: GO S" (GO) NONCE " EVALUATE ; IMMEDIATE
: ;SEE S" ; SEE (GO) NONCE " EVALUATE ; IMMEDIATE
: [TIME ANNOUNCE S" :GO TIMER-RESET #TIMES 0 DO " EVALUATE ; IMMEDIATE
: TIME] S" LOOP .ELAPSED ; GO " EVALUATE ; IMMEDIATE

#1000000000 VALUE #TIMES

TOOL ON RESTORE-INPUT .S .( never get here )

[THEN]

DROP

\ EOF

FORTH> in
Removing --- Ran-Next RNG Version 1.02 ---
Creating --- Ran-Next RNG Version 1.02 ---
Random-Aphwb 2.250 seconds elapsed.
RANDOM-std 2.230 seconds elapsed.
RANDOM2P 9.220 seconds elapsed.
Rand-Next2 3.478 seconds elapsed.
Ran-Next 5.937 seconds elapsed. ok

[Gerry Jackson]

They are useful if you want to scan the input source twice. For example
in the ANS Forth implementation of closures and quotations that I did
some years ago. In a special colon definition the first pass executed
SAVE-INPUT and stacked the input source data in a separate stack,
looking for various words to do with the closures. If nested, SAVE-INPUT
again stacked the input source data.

At the end of each definition RESTORE-INPUT did just that from the
separate stack to compile the source in a second pass. This results in
the innermost definition being compiled first.

In the first version I saved the source text in a buffer before
realising that SAVE and RESTORE-INPUT were a better solution.

It is not much use where a keyboard is the input source as RESTORE-INPUT
is not guaranteed to work and, I suspect that most Forth systems don't
bother to save keyboard input.

--
Gerry

[Ruvim]

On 2023-02-01 10:36, Gerry Jackson wrote:
> On 31/01/2023 22:47, Ruvim wrote:
>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>
>> They are like FILE-POSITION and REPOSITION-FILE, but they work for the
>> current input source.
>>
>> Did anybody use them in programs/libraries? (not in system internals)
>>
>> I can only imagine their application in an interpretive loops
>> implementation. >>
>>
>
> They are useful if you want to scan the input source twice.

I have just realized, they can be used instead of ">IN @ ... >IN !"
But they are more heavy internally.

OTOH, in many cases you don't need to deal with ">in" if you can employ
"execute-parsing".

> For example
> in the ANS Forth implementation of closures and quotations that I did
> some years ago. In a special colon definition the first pass executed
> SAVE-INPUT and stacked the input source data in a separate stack,
> looking for various words to do with the closures. If nested, SAVE-INPUT
> again stacked the input source data.
>
> At the end of each definition RESTORE-INPUT did just that from the
> separate stack to compile the source in a second pass. This results in
> the innermost definition being compiled first.
>
> In the first version I saved the source text in a buffer before
> realising that SAVE and RESTORE-INPUT were a better solution.

I guess this solution is fragile about redefinitions/renames/wrappers, e.g.:

: foo[ postpone [: ; immediate
: ]foo postpone ;] ; immediate

: bar foo[ ... ]foo ... ;

>
> It is not much use where a keyboard is the input source as RESTORE-INPUT
> is not guaranteed to work and, I suspect that most Forth systems don't
> bother to save keyboard input.
>

Yes. It's technically possible, but after the first call of SAVE-INPUT
the system should save all keyboard (or stdin) input forever (till
process termination).


--
Ruvim

[none albert]

In article <trc5pq$3vi3m$1...@dont-email.me>,

Saving and restoring >IN is mostly enough.

I have redesigned SAVE-INPUT RESTORE-INPUT into SAVE and RESTORE
that tuck intermediate results on the return stack.
: EVALUATE SAVE SET-SRC 'INTERPRET CATCH RESTORE THROW ;

INCLUDED is approximately
: INCLUDED GET-FILE EVALUATE ;

So I use it all the time.
I supply SAVE-INPUT for others to use, no big deal:
: SAVE-INPUT SRC 2@ PP @ 3 ;

It comes in handy for EXECUTE-PARSING
: EXECUTE-PARSING ROT ROT SAVE SET-SRC CATCH RESTORE THROW ;

But a normal person would use
\ ( sc - ?? )
SAVE SET-SRC 'whatever CATCH RESTORE THROW ;
or even
SAVE SET-SRC whatever RESTORE
if you don't care about exceptions
(say you're doing a quick and dirty program for taxes.)

Bottom line I reject SAVE-INPUT as a reasonable internal.
The alternative internals I have are definedly useful.
Another example:
: GET-NAME SAVE NAME RESTORE ;
if you have to parse a word two times.

(ABORT") is about the only word in ciforth that is not
independantly useful.

>Ruvim

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[Ruvim]

On 2023-02-01 12:47, albert wrote:
> In article <trc5pq$3vi3m$1...@dont-email.me>,
> Ruvim <ruvim...@gmail.com> wrote:
>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>
>> They are like FILE-POSITION and REPOSITION-FILE, but they work for the
>> current input source.
>>
>> Did anybody use them in programs/libraries? (not in system internals)
>>
>> I can only imagine their application in an interpretive loops
>> implementation.
>
> Saving and restoring >IN is mostly enough.

">IN" should be deprecated in favor of a better API — without changing
an address directly, and with better naming.

May be SAVE-INPUT and RESTORE-INPUT could replace ">IN",
if they will be obligated to always work while REFILL was not performed
between them.

> I have redesigned SAVE-INPUT RESTORE-INPUT into SAVE and RESTORE
> that tuck intermediate results on the return stack.
> : EVALUATE SAVE SET-SRC 'INTERPRET CATCH RESTORE THROW ;

Where does "SAVE" save the data?

SP-Forth/4 employs SAVE-SOURCE ( -- i*x u.i )
and RESTORE-SOURCE ( i*x u.i -- ) for that:

: EVALUATE-WITH ( i*x c-addr u xt -- j*x )
SAVE-SOURCE N>R
>R SOURCE! -1 TO SOURCE-ID
R> CATCH
NR> RESTORE-SOURCE
THROW
;
: EVALUATE ( i*x c-addr u -- j*x ) \ 94
['] INTERPRET EVALUATE-WITH

;


>
> INCLUDED is approximately
> : INCLUDED GET-FILE EVALUATE ;
>
> So I use it all the time.
> I supply SAVE-INPUT for others to use, no big deal:
> : SAVE-INPUT SRC 2@ PP @ 3 ;
>
> It comes in handy for EXECUTE-PARSING
> : EXECUTE-PARSING ROT ROT SAVE SET-SRC CATCH RESTORE THROW ;
>
> But a normal person would use
> \ ( sc - ?? )
> SAVE SET-SRC 'whatever CATCH RESTORE THROW ;

Why not
'whatever EXECUTE-PARSING
?

> or even
> SAVE SET-SRC whatever RESTORE
> if you don't care about exceptions
> (say you're doing a quick and dirty program for taxes.)
>
> Bottom line I reject SAVE-INPUT as a reasonable internal.

I see. I asked about programs/libraries — obviously, you don't have
examples of use them too.


--
Ruvim

[Gerry Jackson]

Yes it is a limitation of the program that it cannot handle immediate
user defined parsing words such as your FOO[ inside a colon definition.
It can handle standard parsing words such as POSTPONE S" etc, and
comments but not [IF] etc and DOES> where it aborts. These are
documented as restrictions.

But it could still pass Knuth's Man or Boy test as a man.

>
>>
>> It is not much use where a keyboard is the input source as
>> RESTORE-INPUT is not guaranteed to work and, I suspect that most Forth
>> systems don't bother to save keyboard input.
>>
>
> Yes. It's technically possible, but after the first call of SAVE-INPUT
> the system should save all keyboard (or stdin) input forever (till
> process termination).

Wouldn't a definition ABORTing abandon saving of keyboard input or do
you consider that as 'process termination'? What about the value
returned by KEY?

--
Gerry

[Ruvim]

On 2023-02-01 18:03, Gerry Jackson wrote:
> On 01/02/2023 12:42, Ruvim wrote:
>> On 2023-02-01 10:36, Gerry Jackson wrote:

[...]

>>>
>>> It is not much use where a keyboard is the input source as
>>> RESTORE-INPUT is not guaranteed to work and, I suspect that most
>>> Forth systems don't bother to save keyboard input.
>>>
>>
>> Yes. It's technically possible, but after the first call of SAVE-INPUT
>> the system should save all keyboard (or stdin) input forever (till
>> process termination).
>
> Wouldn't a definition ABORTing abandon saving of keyboard input or do
> you consider that as 'process termination'?

I mean the keyboard as far as it's the user input device that is the
input source. For example, in a case of an interactive session.
I think, it should not save keyboard events, but only characters that
are read by REFILL under the hood.

This can be schematically represented as:

keyboard ==> the user input device ==> the input source ==> refill

Or, in a case of input from a file:

the file ==> the input source ==> refill

But in the case of a file there is no need to save the characters since
the file read position can be changed back (as well as the content of
the input buffer and ">IN").


By process termination I mean the action of BYE (or alike).

When ABORT is performed, and it's not caught (by CATCH), you can still
perform RESTORE-INPUT (or another word that calls this one)
interactively, even several times. So the saved characters cannot be
abandoned.

> What about the value returned by KEY?

KEY (and ACCEPT) does not read the input source, but the user input device.

RESTORE-INPUT does reposition of the input source. I think, it should
not affect the user input device, and hence it should not affect KEY.


--
Ruvim

[none albert]

In article <tre9hh$ebbc$1...@dont-email.me>,

My take on it is that ABORT is a system restart. Implementing ABORT
via a THROW is an abomination. If you want THROW , you know where to
find them.
Implementing endless layers of recovery serves no purpose. The
certainty that you have a word that kills and restarts trustworthy
everything going on, is on the other hand eminently useful. Don't use
it if you don't want that.

>
>--
>Gerry

[none albert]

In article <tregkg$fqq8$1...@dont-email.me>, Ruvim <ruvim...@gmail.com> wrote:
>On 2023-02-01 18:03, Gerry Jackson wrote:
>> On 01/02/2023 12:42, Ruvim wrote:
>>> On 2023-02-01 10:36, Gerry Jackson wrote:
>[...]
>>>>
>>>> It is not much use where a keyboard is the input source as
>>>> RESTORE-INPUT is not guaranteed to work and, I suspect that most
>>>> Forth systems don't bother to save keyboard input.
>>>>
>>>
>>> Yes. It's technically possible, but after the first call of SAVE-INPUT
>>> the system should save all keyboard (or stdin) input forever (till
>>> process termination).
>>
>> Wouldn't a definition ABORTing abandon saving of keyboard input or do
>> you consider that as 'process termination'?
>
>
>I mean the keyboard as far as it's the user input device that is the
>input source. For example, in a case of an interactive session.
>I think, it should not save keyboard events, but only characters that
>are read by REFILL under the hood.

REFILL is a cludge inherited from the time, the terminal input buffer
was to serve double purpose. TIB #TIB was abandoned but not so REFILL.
There isn't ever needed a REFILL except for the terminal input buffer
aptly named REFILL-TIB. It reads a line from the terminal,
approximately READ-FILE from standard in.

Nowadays REFILL is only used to interpret a source file line by line.
So lina has to supply them as a loadable extension, but otherwise
has no employment for it.

>
>This can be schematically represented as:
>
> keyboard ==> the user input device ==> the input source ==> refill
>
>Or, in a case of input from a file:
>
> the file ==> the input source ==> refill
>
>But in the case of a file there is no need to save the characters since
>the file read position can be changed back (as well as the content of
>the input buffer and ">IN").
>
>
>By process termination I mean the action of BYE (or alike).
>
>When ABORT is performed, and it's not caught (by CATCH), you can still
>perform RESTORE-INPUT (or another word that calls this one)
>interactively, even several times. So the saved characters cannot be
>abandoned.

Bad idea. Your system is running through hoops, for what?

>
>
>> What about the value returned by KEY?
>
>KEY (and ACCEPT) does not read the input source, but the user input device.

KEY? is inspecting if an asynchronous event had taken place.
Is has virtually nothing to do with the user input device.
A testament to that is that the implementation is totally different.
Then you have to read the input character ...
It would be better to have a BREAK? that senses the 'break' key on the
keyboard, or a delayed action on ^C.

>
>RESTORE-INPUT does reposition of the input source. I think, it should
>not affect the user input device, and hence it should not affect KEY.

I really don't understand this. The system doesn't take action until you
hit return. From that moment on the terminal input buffer should
be frozen until OK-time. You could do RESTORE-INPUT that is a posh word
to saving and restoring >IN.
Whether KEY's are stored in a type ahead buffer or ignored is neither
here not there.

>--
>Ruvim

[Hans Bezemer]

On Thursday, February 2, 2023 at 11:58:34 AM UTC+1, none albert wrote:
> My take on it is that ABORT is a system restart. Implementing ABORT
> via a THROW is an abomination. If you want THROW , you know where to
> find them.
> Implementing endless layers of recovery serves no purpose. The
> certainty that you have a word that kills and restarts trustworthy
> everything going on, is on the other hand eminently useful. Don't use
> it if you don't want that.

I tend to agree with you. If you want to leave, leave. If you want to think about
it, think about it. For that purpose I created THROW" - which is the "think about
it" variant of ABORT". But ABORT does exactly what it says on the label. It aborts.

Hans Bezemer

[Hans Bezemer]

On Thursday, February 2, 2023 at 12:22:52 PM UTC+1, none albert wrote:
> There isn't ever needed a REFILL except for the terminal input buffer
> aptly named REFILL-TIB. It reads a line from the terminal,
> approximately READ-FILE from standard in.
>
> Nowadays REFILL is only used to interpret a source file line by line.
> So lina has to supply them as a loadable extension, but otherwise
> has no employment for it.

Here we differ. In 4tH, if you want to read chunks of raw data, you use
ACCEPT. REFILL reads lines.

But note that 4tH has a vastly different file mechanism. Each input or
output word (yes, even TYPE, . or .") can write to an output file. If you
open a file in 4tH, you've opened a stream. The word USE connects this
stream to (depending HOW you opened it) the input and/or the output
channel.

Therefore, there is no distinction between text or binary mode. Treat it like
a text file (e.g. by using REFILL) and it is a text file. Treat it like a binary file
(e.g. by using ACCEPT) and it is a binary file.

Consequently, it is trivial to define the ANS FILE wordset in 4tH, but almost
impossible to implement 4tHs way of handling files in ANS.

Hans Bezemer

[none albert]

In article <e8af60ca-38af-4cda...@googlegroups.com>,

Hans Bezemer <the.bee...@gmail.com> wrote:
>On Thursday, February 2, 2023 at 12:22:52 PM UTC+1, none albert wrote:
>> There isn't ever needed a REFILL except for the terminal input buffer
>> aptly named REFILL-TIB. It reads a line from the terminal,
>> approximately READ-FILE from standard in.
>>
>> Nowadays REFILL is only used to interpret a source file line by line.
>> So lina has to supply them as a loadable extension, but otherwise
>> has no employment for it.
>Here we differ. In 4tH, if you want to read chunks of raw data, you use
>ACCEPT. REFILL reads lines.

ACCEPT in ciforth's lina64 docs:
Transfer at most count characters from the terminal to address, until
a RET is received. The simple tty editing functions of Linux are
observed, i.e. the ``erase'' (delete a character) and ``kill'' (delete
a line) characters. Typically these are the backspace key and ^U. Note
that excess characters after count are ignored. The number of
characters not including the RET is returned into n.

This is in accordance with the ISO standard (hopefully).
Anyhow the standard is clear that ACCEPT reads lines with printable
char's from a terminal.
An implication is that it is related to keyboard events and ascii
characters and it is happening in real time not batch, and there
can be indeterminate delays between events, not related to the speed
of the CPU.

Actually your ACCEPT is the opposite, raw data input?

>But note that 4tH has a vastly different file mechanism. Each input or
>output word (yes, even TYPE, . or .") can write to an output file. If you
>open a file in 4tH, you've opened a stream. The word USE connects this
>stream to (depending HOW you opened it) the input and/or the output
>channel.
>
>Therefore, there is no distinction between text or binary mode. Treat it like
>a text file (e.g. by using REFILL) and it is a text file.
>Treat it like a binary file
>(e.g. by using ACCEPT) and it is a binary file.
>
>Consequently, it is trivial to define the ANS FILE wordset in 4tH, but almost
>impossible to implement 4tHs way of handling files in ANS.

Yeah, quite different.
I am quite fond of the unix paradigm, a file is a sequence of bytes.
One of my jobs:
The sorting of Van Dalen's dictionary went from 2 days on a pdp 11
to minutes on a VAX. Unfortunately with the different file types
on the VAX VMS, have to use strange file types and the program took
5 times as long as necessary.
(The customer was quite happy though).

>
>Hans Bezemer

[Ruvim]

On 2023-01-31 22:47, Ruvim wrote:
> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>
> They are like FILE-POSITION and REPOSITION-FILE, but they work for the
> current input source.
>
> Did anybody use them in programs/libraries? (not in system internals)
>

Don't you think these words can be destandardized due to their little
usefulness?

What is a better API to replace them?


--
Ruvim

[none albert]

In article <trmbli$23fon$1...@dont-email.me>,

You don't mean FILE-POSITION and REPOSITION-FILE , I hope?
They are quite useful.

>--
>Ruvim

[Ruvim]

On 2023-02-04 19:55, albert wrote:
> In article <trmbli$23fon$1...@dont-email.me>,
> Ruvim <ruvim...@gmail.com> wrote:
>> On 2023-01-31 22:47, Ruvim wrote:
>>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>>
>>> They are like FILE-POSITION and REPOSITION-FILE, but they work for the
>>> current input source.
>>>
>>> Did anybody use them in programs/libraries? (not in system internals)
>>>
>>
>>
>> Don't you think these words can be destandardized due to their little
>> usefulness?
>>
>> What is a better API to replace them?
>
> You don't mean FILE-POSITION and REPOSITION-FILE , I hope?

Yes, I don't mean that.

Actually, to think about another API, it should be clear what a problem
this API should solve. I just don't have an idea in this regard.


--
Ruvim

[dxforth]

If those words have little use, then what is the case for replacing them?

[Ruvim]

If a reason of little use is their inconvenient API.
Or if somebody think that a program should anyway be able to extract an
arbitrary part of the input source (following the current position) and
include/translate it multiple times.

Without RESTORE-INPUT a program can save a part of the input source into
the memory, but it's difficult to include it, since if EVALUATE is used,
the line comment ("\") and PARSE work till the end of the memory region,
instead of a line terminator.

--
Ruvim

[Gerry Jackson]

On 05/02/2023 12:49, Ruvim wrote:
> On 2023-02-05 03:48, dxforth wrote:
>> On 5/02/2023 6:28 am, Ruvim wrote:
>>> On 2023-01-31 22:47, Ruvim wrote:
>>>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>>>
>>>> They are like FILE-POSITION and REPOSITION-FILE, but they work for
>>>> the current input source.
>>>>
>>>> Did anybody use them in programs/libraries? (not in system internals)
>>>
>>> Don't you think these words can be destandardized due to their little
>>> usefulness?
>>>
>>> What is a better API to replace them?
>>
>> If those words have little use, then what is the case for replacing them?
>>
>
> If a reason of little use is their inconvenient API.

What is their inconvenient API? It seems ok to me. Before words get
removed from the standard their use should be deprecated for some years
to enable users to adjust to their absence.

You should not regard response on comp.lang.forth as covering all Forth
programmers. I think many people are driven away by the toxic posters we
have.


--
Gerry

[Ruvim]

On 2023-02-05 13:02, Gerry Jackson wrote:
> On 05/02/2023 12:49, Ruvim wrote:
>> On 2023-02-05 03:48, dxforth wrote:
>>> On 5/02/2023 6:28 am, Ruvim wrote:
>>>> On 2023-01-31 22:47, Ruvim wrote:
>>>>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>>>>
>>>>> They are like FILE-POSITION and REPOSITION-FILE, but they work for
>>>>> the current input source.
>>>>>
>>>>> Did anybody use them in programs/libraries? (not in system internals)
>>>>
>>>> Don't you think these words can be destandardized due to their
>>>> little usefulness?
>>>>
>>>> What is a better API to replace them?
>>>
>>> If those words have little use, then what is the case for replacing
>>> them?
>>>
>>
>> If a reason of little use is their inconvenient API.
>
> What is their inconvenient API? It seems ok to me.

The standard does not require them to work for any input source.

They cannot help if you need to include a saved portion when the
source-id is changed.

In one my task I need exactly that — saving a portion of the input
source to later include it in other contexts regardless the source-id.

> Before words get
> removed from the standard their use should be deprecated for some years
> to enable users to adjust to their absence.

Agreed. I just ask what people think.

>
> You should not regard response on comp.lang.forth as covering all Forth
> programmers. I think many people are driven away by the toxic posters we
> have.

I also asked about use cases in ForthHub/discussions and in EuroForth chat.


--
Ruvim

[dxforth]

On 6/02/2023 12:02 am, Gerry Jackson wrote:
> On 05/02/2023 12:49, Ruvim wrote:
>> On 2023-02-05 03:48, dxforth wrote:
>>> On 5/02/2023 6:28 am, Ruvim wrote:
>>>> On 2023-01-31 22:47, Ruvim wrote:
>>>>> It seems the words SAVE-INPUT and RESTORE-INPUT are not quite useful.
>>>>>
>>>>> They are like FILE-POSITION and REPOSITION-FILE, but they work for the current input source.
>>>>>
>>>>> Did anybody use them in programs/libraries? (not in system internals)
>>>>
>>>> Don't you think these words can be destandardized due to their little usefulness?
>>>>
>>>> What is a better API to replace them?
>>>
>>> If those words have little use, then what is the case for replacing them?
>>>
>>
>> If a reason of little use is their inconvenient API.
>
> What is their inconvenient API? It seems ok to me. Before words get removed from the standard their use should be deprecated for some years to enable users to adjust to their absence.

The last release was 2012 so that would seem to cover it. But such concerns
seem premature considering there's not even been an RfD AFAIK.

> You should not regard response on comp.lang.forth as covering all Forth programmers. I think many people are driven away by the toxic posters we have.

Unless I'm mistaken 200x is required to conduct discussions through c.l.f.
However as 200x now has its own forum it can do its business there, avoiding
those it deems suppressive. I can't speak for c.l.f. but I have no objections
to such a move.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>On 6/02/2023 12:02 am, Gerry Jackson wrote:
>> What is their inconvenient API? It seems ok to me. Before words get removed from the standard their use should be deprecated for some years to enable users to adjust to their absence.
>
>The last release was 2012 so that would seem to cover it.

These words have not been marked as obsolescent in 2012. If someone
succeeds with the proposal to eventually remove these words, they will
be marked as obsolescent in the next standard, and expected to be
removed in the release after that.

>Unless I'm mistaken 200x is required to conduct discussions through c.l.f.

Not any longer. All online discussions are on forth-standard.org. If
I do a proposal of wider interest, I usually post a pointer here,
however.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[dxforth]

On 6/02/2023 3:12 am, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
> ...

>> Unless I'm mistaken 200x is required to conduct discussions through c.l.f.
>
> Not any longer. All online discussions are on forth-standard.org. If
> I do a proposal of wider interest, I usually post a pointer here,
> however.

ANS/200x is in its heaven and all's well with the world. No more walking on
eggshells lest someone be offended at the idea it be just a tool and product
of the mind deserving of no special consideration or reverence.