-
Notifications
You must be signed in to change notification settings - Fork 1
/
output-redirection.html
97 lines (66 loc) · 2.64 KB
/
output-redirection.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
<title>Output redirection proposal</title>
<h3><a name="output-redirection">Output redirection</a></h3>
[<a href="proposals.html">Other proposals</a>]
<h4>Problem</h4>
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.
<h4>Proposal</h4>
<pre>
redirect-output ( ... file-id xt -- ... ) file-ext
</pre>
Set the user output device to file-id, EXECUTE xt, restore the old
user output device. If an exception is THROWn during the execution of
xt, the old user output device is restored, and the exception is
THROWn onwards.
<h4>Typical Use</h4>
<pre>
... ( r ) report-file @ ['] f. redirect-output ...
</pre>
<h4>Remarks</h4>
The syntax is CATCH-like to ensure proper restoration under all
circumstances (including THROWs). A more convenient syntax should be
found for CATCH as well as redirect-output.
<p>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.
<p>Why not simply have a variable for the output file, similar to
BASE? Providing varying bases through a variable BASE was a mistake; I
am sure no Forth programmer will have trouble reciting a story where
BASE lead to problems. A similar design mistake for output redirection
would cause more trouble (e.g., some bug causes a THROW while output
is redirected -> the user does not even know that something happened).
<p>STDOUT is used in Gforth for the default OUTFILE-ID (i.e., the
standard output at the start of the system).
<h4>Experience</h4>
none
<h4>Comments</h4>
Michael L. Gassanenko:
<pre>
xt... It smells LISP, and I do not like LISP smell in Forth.
maybe,
<fid> redirect-output N>R .... NR> restore-output
would be better than
: aux14 ." xt=" MYVAR @ U. ;
... <fid> ['] aux14 redirect-output
?
What about redirecting output to strings? (IMO, it would be more useful)
</pre>
Michael L. Gassanenko again, about redirection to memory:
<pre>
What hapens if the memory buffer being the current output device
overflows?
</pre>
Peter Knaggs:
<pre>
REDIRECTE-OUTPUT
OUTFILE-ID
Not so sure about these two. Why not define a STDIN and STDOUT words
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, simular to BASE if you like.
Note that I did suggest something along these lines to the committee
back in '90 but it was rejected.
</pre>
<hr><a href="http://www.complang.tuwien.ac.at/anton/">Anton Ertl</a>