Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #134669

Re: How does the input stream traditionally work?

Show all headers | View raw

On Sat, 14 Mar 2026 15:09:24 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> peter <peter.noreply@tin.it> writes:
> >On Fri, 13 Mar 2026 15:10:13 -0700
> >Paul Rubin <no.email@nospam.invalid> wrote:
> >
> >> They can really be nested, right?
> [...]
> >Check out the standard words SAVE-INPUT and RESTORE-INPUT!
> 
> I don't think there is anything to check out:
> 
> 1) If you want to treat RESTORE-INPUT a reliable component (i.e.,
>    whenever you give it an input produced by SAVE-INPUT, it restores
>    the input source specification and returns false), I don't see how
>    to reconcile this with the nesting of INCLUDED, EVALUATE and LOAD.
>    E.g., consider:
> 
>    File a.4th:
>    --------------
>    .( a)
>    include b.4th
>    .( b)
>    restore-input abort" RESTORE-INPUT cannot restore input source specification"
>    .( c)
>    --------------
> 
>    File b.4th:
>    -------------
>    .( d)
>    save-input
>    .( e)
> 
>    what should this code output?
on LXF64 it outputs adeb and then crashes!
I think that is expected. It crashes as save-input save the input for b.4th
but include b.4th does a restore input and also closes the b.4th file-mapping
as it is ready using it. when the next restore-input comes it restores again
the input but now the file-mapping is gone and it crashes when reading from
non existing memory.

> 
> 2) OTOH, if you consider the allowance for systems to let
>    RESTORE-INPUT return true, it is certainly not useful for
>    implementing INCLUDED and friends, unless you have extra knowledge
>    about the concrete implementation of SAVE-INPUT and RESTORE-INPUT,
>    in which case Paul Rubin would have to check out that particular
>    implementation, not the standard words.
> 
>    E.g., in Gforth RESTORE-INPUT returns false only if the source-id
>    is the same as on SAVE-INPUT, so in Gforth SAVE-INPUT and
>    RESTORE-INPUT are completely useless for implementing INCLUDED and
>    friends.
> 
>    In the extreme, the following implementation of these words
>    satisfies the requirements of the standard, but is absolutely
>    useless:
>    : SAVE-INPUT ( -- ) ;
>    : RESTORE-INPUT ( -- f ) true ;
> 
> Actually, looking at
> <https://forth-standard.org/standard/rationale#rat:core:SAVE-INPUT>, I
> find that the committee intended the usage that Gforth supports, and
> nothing more.  This rationale even claims that a usage that tries to
> unnest the input stream using RESTORE-INPUT is non-standard (but I
> don't read that out of the normative text).
> 
> >Here is Evaluate from ntf64 as an example
> >
> >: EVALUATE ( addr u -- )
> >	save-input 2>r 
> >	(#src) ! (src) !  0 >in ! -1 sid ! 0 blk ! ['] refill-evaluate [refill] !	
> >	s" Evaluate:" sourcename place
> >	['] interpret catch
> >	dup -1 < if .source then
> >	2r> restore-input drop 
> >	throw ;
> 
> It looks like you make use of carnal knowledge about how your
> SAVE-INPUT and RESTORE-INPUT is implemented, including knowledge of
> the number of stack items pushed by SAVE-INPUT, and DROPping the flag
> that indicates the success or failure of RESTORE-INPUT.

Yes SAVE-INPUT and RESTORE-INPUT is coded to work in INCLUDE EVALUATE etc.
And for sure I use that fully.

I have always thought that that was the main use for them!

Thanks to the way input variables are organized they are very simple

: SAVE-INPUT  ( -- addr 1 )
	input-source @ 
	include-buffer dup input-source !
	over swap icb-len move
	1  ; 

: RESTORE-INPUT ( addr n -- f )
	1 <> abort" Bad restore-input" 
	input-source @ free throw
	input-source !
	blk-fix
	0 ;

include-buffer just allocates icb-len of space

This works for INCLUDE etc and also passes Garry Jackssons test suit

BR
Peter

> 
> - anton

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-13 15:10 -0700
  Re: How does the input stream traditionally work? peter <peter.noreply@tin.it> - 2026-03-14 10:12 +0100
    Re: How does the input stream traditionally work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-14 15:09 +0000
      Re: How does the input stream traditionally work? peter <peter.noreply@tin.it> - 2026-03-14 23:30 +0100
        Re: How does the input stream traditionally work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-15 14:02 +0000
          Re: How does the input stream traditionally work? albert@spenarnc.xs4all.nl - 2026-03-15 19:25 +0100
  Re: How does the input stream traditionally work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-14 11:26 +0000
    Re: How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-14 23:34 -0700
      Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-03-15 18:26 +1100
        Re: How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-15 13:21 -0700
          Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-03-16 10:46 +1100
            Re: How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-15 18:09 -0700
              Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-03-16 13:13 +1100
                Re: How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-16 15:14 -0700
                Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-03-17 10:37 +1100
                Re: How does the input stream traditionally work? Paul Rubin <no.email@nospam.invalid> - 2026-03-16 17:27 -0700
                Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-03-17 12:48 +1100
                Re: How does the input stream traditionally work? albert@spenarnc.xs4all.nl - 2026-03-17 11:16 +0100
                Re: How does the input stream traditionally work? Gerry Jackson <do-not-use@swldwa.uk> - 2026-03-17 11:27 +0000
            Re: How does the input stream traditionally work? dxf <dxforth@gmail.com> - 2026-04-21 18:40 +1000
              Re: How does the input stream traditionally work? albert@spenarnc.xs4all.nl - 2026-04-21 12:39 +0200
              Re: How does the input stream traditionally work? Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-21 19:47 +0200
      Re: How does the input stream traditionally work? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-15 16:29 +0000
        Re: How does the input stream traditionally work? albert@spenarnc.xs4all.nl - 2026-03-15 19:48 +0100
  Re: How does the input stream traditionally work? albert@spenarnc.xs4all.nl - 2026-03-14 15:33 +0100

csiph-web