|
996
|
1 One aspect of INTERCAL-72 that was never fully documented was the way
|
|
|
2 in which IGNORE and RETRIEVE statements interacted. It turns out that
|
|
|
3 the three modern INTERCAL compilers all use slightly different
|
|
|
4 definitions.
|
|
|
5
|
|
|
6 The associated program ignorret.i stores 1 in a variable's stash, 2 in
|
|
|
7 the variable itself, ignores the variable, and retrieves it; it then
|
|
|
8 prints out the variable, and tests to see whether the variable is
|
|
|
9 ignored.
|
|
|
10
|
|
|
11 C-INTERCAL prints:
|
|
|
12
|
|
|
13 II
|
|
|
14
|
|
|
15 II
|
|
|
16 In other words, the interpretation used is that the variable is
|
|
|
17 read-only, so a RETRIEVE can't change its value (but instead just
|
|
|
18 discards the stash item). The variable remains IGNOREd.
|
|
|
19
|
|
|
20 J-INTERCAL prints:
|
|
|
21
|
|
|
22 I
|
|
|
23
|
|
|
24 I
|
|
|
25 J-INTERCAL doesn't take the interaction between IGNORE and RETRIEVE
|
|
|
26 into account at all; the RETRIEVE just does what a RETRIEVE would
|
|
|
27 normally do, which is to set the variable from its own stack. The
|
|
|
28 variable remains IGNOREd.
|
|
|
29
|
|
|
30 CLC-INTERCAL prints:
|
|
|
31 I
|
|
|
32 III
|
|
|
33 The interpretation used by CLC-INTERCAL is somewhat different. The
|
|
|
34 ignorance status is stashed along with the variable itself; so the
|
|
|
35 value of 1 is read from the variable's stash, but doing so also
|
|
|
36 removes the read-only status of the variable. This means that the
|
|
|
37 third assignment to the variable works, unlike in the other two
|
|
|
38 cases. (Note that CLC-INTERCAL will act like C-INTERCAL on the
|
|
|
39 ignorret test when running in C-INTERCAL compatibility mode.)
|
|
|
40
|
|
|
41 The upshot of all this is: don't RETRIEVE a read-only variable if you
|
|
|
42 want your program to be portable!
|
|
|
43
|
|
|
44 Alex Smith
|
