Does ACCEPT read from other sources?

[SirWumpus]

When ACCEPT is called by INCLUDE or LOAD (or redirected standard input) should it read input from that source?

Consider this fragment a.4th:

PAD /PAD ACCEPT
Say something clever.
PAD SWAP '>' EMIT TYPE

Now INCLUDE it:

ok INCLUDE a.fth
>Say something clever.
ok

Is this correct expected behaviour?

Update 0

Created some test cases for thought:

cat <<EOF >accept.p4
PAD /PAD ACCEPT
Say something clever.
EOF

t{ INCLUDE accept.p4 PAD SWAP S\" Say something clever.\n" COMPARE -> 0 }t
PAD /PAD ERASE
t{ PAD /PAD S\" ACCEPT\nSalut tout monde." EVALUATE PAD SWAP S" Salut tout monde." COMPARE -> 0 }t

[frenchie68]

Hi Tony, I love the behaviour which is akin to HERE< in the Unix shell. I looked up my database of Forth standards. Only 79-STANDARD ('EXPECT') specified that input is to be read from "the terminal." Later standards say nothing about what the input stream is--they do not even refer to an input stream. Clearly, you are in unspecified territory. The prevailing theory goes like this: if you can pass Gerry Jackson's test suite, then your implementation is acceptable. It's some argument from authority but there you go... Adding a clarification to the specification has, of course, political implications. Being on the Forth2012 standardization committee, I see two options at this point: [1] we leave it open as it is and your implementation is compliant. [2] we specify that the input had to be supplied by the system console (BLK @ is zero). In which case your code would be not compliant. Please keep me informed as to which avenue would best suit you. [Note] My own implementation reads from the console. Which absolutely does not mean you could operate in a different way. Right now, I do not understand how this could be done in block context. It might; I'm just not there yet! All the best.         Francois Ref: https://github.com/gerryjackson/forth2012-test-suite 

[ruv]

6.1.0695 ACCEPT says: Receive a string of at most +n1 characters. (emphasis mine)

The word "receive" is a formal term, the meaning of which is defined in the section 2.1 Definitions of terms:

receive: To obtain characters from the user input device.
user input device: The input device currently selected as the source of received data, typically a keyboard.

A file included via included or include-file typically is not the user input device. But some files (for example, /dev/stdin) can be the user input device, because The method of selecting the user input device is implementation defined (3.2.4.1 User input device).

This means that ACCEPT must obtain characters from the same device as KEY.

[frenchie68]

Thank you for your explanation of the standard, Ruvin. It seems I should read it again! That being said, if you use the standard as a reference guide (which I often do), this is not immediately apparent. Maybe we should add an explicit reference in the "ACCEPT" specification to "user input device" as an entry in section 2.1 ("2 Terms, notation, and references").

In essence (3.2.4.1 User input device) says, as an end user, you're free to re-assign the "user input device" the way you see fit.

[ruv]

this is not immediately apparent. Maybe we should add an explicit reference in the "ACCEPT" specification to "user input device"

Yes, or maybe every mention of a normative term should have a link to its definition. I noted this idea in ForthHub/standard-evolution.

[SirWumpus]

3.2.4.1 User input device:

The method of selecting the user input device is implementation defined.

So that means my test would be compliant, because they select a user input device in a implementation defined manner. ie. the current input source. There is nothing that says the user input device has to be interactive (or that the user is a hoooman, monkey, or robot).

[ruv]

So that means my test would be compliant, because they select a user input device in a implementation defined manner.
ie. the current input source.

I think, that would mean that INCLUDE switches the user input device before interpreting the file content. This action is not specified in its glossary entry, and the effect of this action can be detected by a standard program. Thus, such an implementation is not allowed for a standard system.

A compliant way is to provide a system-specific word to switch the user input device.

There is nothing that says the user input device has to be interactive (or that the user is a hoooman, monkey, or robot).

Of course, a file can be used as the user input device.

[frenchie68]

I ultimately came up with a solution, limited to one line, in block context. This was hard!

[ruv]

Thank you! Maybe it is better to post a text instead of a screenshot )

[frenchie68]

Happy to oblige. The restrictions stated in my previous post remain!

SOURCE DROP >IN @ $3F INVERT AND +
$80 + DUP $40 + SOURCE DROP - >IN !
Vanitas vanitatum et omnia vanitas.
CR CHAR > EMIT $3F TYPE