Mercurial > repo

comparison interps/c-intercal/pit/tests/ignorret.doc @ 996:859f9b4339e6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
<Gregor> tar xf egobot.tar.xz
author HackBot
date Sun, 09 Dec 2012 19:30:08 +0000
parents
children
comparison
equal deleted inserted replaced
995:6883f5911eb7 996:859f9b4339e6
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