Error output for a hosted Forth?

[SirWumpus]

Given Forth's history, there is typically only one output stream for Forth, but for a hosted Forth on a POSIX system, there are typically two output streams available: stdout and stderr.

For a hosted Forth should error messages be written to:

• standard output
• standard error
• doesn't matter, Forth 200x draft 19-1 is silent on the matter, just documented it

[MitchBradley]

It's up to you based on how you intend to use the system. stdout and stderr are artifacts of Unix history, where shell commands were run in pipelines where downstream components were not prepared to deal with "unusual" error output. That model does not match conventional modern usage very much, especially as it comes to Forth, which is rarely used to implement standalone Posix commands that appear in pipelines. The disconnect between that historical design approach and modern usage is so great that the question is hard to answer in any definitive way. My cforth system, when hosted, uses stderr for crash-level messages where Forth can't start properly or otherwise blows up, but everything that comes from Forth code goes to stdout.

[ruv]

I use Forth for command line utilities. Sometimes my program consumes text from the standard input, transforms it, and produces text to the standard output. So it's preferred that a Forth system I use for this supports some kind of batch mode, and outputs errors not to stdout, but to stderr (because stdout can be redirected to a file, and its contents must be in some specific format).

Also, in batch mode, a Forth system itself should not show output any information at startup, such as a boot message or banner.
See also the banner discussion for Gforth.

[SirWumpus]

What about the ok prompt? Should that be suppressed in batch/pipe mode?

[ruv]

In the case of transforming data from stdin, a program takes control before the system's REPL (the word quit) can be started, and the program reads all stdin using refill. So, the Forth system don't have a chance to show a prompt.

There is another scenario, when a Forth program text (for example, one automatically generated by another program) is passed to a Forth system via the standard input rather than via a file. In this case, it is not desirable for the Forth system to display (or output to stdout) a prompt after each interpreted line.

Also, in batch mode, a Forth system should not to continue interpreting stdin if some uncaught error or exception occurs.

[ruv]

Regarding error messages. Anyway, If I, as a Forth system implementer, am unsure whether error messages should go to stdout or stderr, I will probably create a command line option 🙃

[SirWumpus]

Regarding error messages. Anyway, If I, as a Forth system implementer, am unsure whether error messages should go to stdout or stderr, I will probably create a command line option 🙃

Eww.

[ruv]

Well, maybe a system-specific Forth word like set-stderr ( fileid -- ), along with stdout ( -- fileid ) and stderr ( -- fileid ).