MAE/4
M. Anton Ertl (anton@mips.complang.tuwien.ac.at)
Many words exist for convenient output to the user output device (e.g.,.,.S,F.). Replicating this functionality for output to files is very cumbersome and a lot of work.
Set the user output device to file-id,redirect-output( file-id xt -- ) file-extEXECUTExt, restore the old user output device. If an exception isTHROWn during the execution of xt, the old user output device is restored, and the exception isTHROWn onwards.
( r ) report-file @ ['] f. redirect-output
The syntax isCATCH-like to ensure proper restoration under all circumstances (includingTHROWs). A more convenient syntax should be found forCATCHas well as redirect-output.Michael Gassanenko's point about output to memory is a good one. Either we address this by adding words for creating fids for memory buffers, or we change this proposal to take an xt ( c-addr u -- ) instead of a fid.
Why not simply have a variable for the output file, similar to
BASE?Providing varying bases through a variableBASEwas a mistake; I am sure no Forth programmer will have trouble reciting a story whereBASElead to problems. A similar design mistake for output redirection would cause more trouble (e.g., some bug causes aTHROWwhile output is redirected => the user does not even know that something happened).
STDOUTis used in Gforth for the defaultOUTFILE-ID(i.e., the standard output at the start of the system).
none
- Michael L. Gassanenko:
- xt... It smells LISP, and I do not like LISP smell in Forth.
maybe,
redirect-output N>R ... NR> restore-output would be better than
What about redirecting output to strings? (IMO, it would be more useful): aux14 ." xt=" MYVAR @ U. ; ...['] aux14 redirect-output What hapens if the memory buffer being the current output device overflows?
- Peter Knaggs:
- Why not define a
STDINandSTDOUTwords witch provide the standard fild-id for terminal I/O and redefine all I/O words to be file based. Thus redirecting output would simply be a case of changing the output file id.