|
996
|
1 <HTML>
|
|
|
2 <HEAD>
|
|
|
3 <TITLE>CLC-INTERCAL Reference</TITLE>
|
|
|
4 </HEAD>
|
|
|
5 <BODY>
|
|
|
6 <H1>CLC-INTERCAL Reference</H1>
|
|
|
7 <H2>... Belongs TO</H2>
|
|
|
8
|
|
|
9 <P>
|
|
|
10 Table of contents:
|
|
|
11 <UL>
|
|
|
12 <LI><A HREF="index.html">Parent directory</A>
|
|
|
13 <LI><A HREF="#belongs">Belongs TO</A>
|
|
|
14 </UL>
|
|
|
15 </P>
|
|
|
16
|
|
|
17 <H2><A NAME="belongs">Belongs To</A></H2>
|
|
|
18
|
|
|
19 <P>
|
|
|
20 CLC-INTERCAL introduces an unique infrastructure over the registers. We
|
|
|
21 shall explain it with an example.
|
|
|
22 </P>
|
|
|
23
|
|
|
24 <P>
|
|
|
25 Imagine building a tree structure in other languages. You have a root, and
|
|
|
26 there are pointers from the root to other nodes, which in turn have pointers
|
|
|
27 to other nodes, until you get to the leaves.
|
|
|
28 </P>
|
|
|
29
|
|
|
30 <P>
|
|
|
31 This all sounds simple, but it has several drawbacks. The most important,
|
|
|
32 is that each node can have an arbitrary number of children, so you need to
|
|
|
33 start using messy techniques like variable-length lists. Also, if the
|
|
|
34 nodes need to contain values as well as pointers, you need to remember
|
|
|
35 reserving the extra space.
|
|
|
36 </P>
|
|
|
37
|
|
|
38 <P>
|
|
|
39 CLC-INTERCAL does not suffer from these problems. By simply reversing the
|
|
|
40 pointers, you can easily see that any leave or node has exactly one parent.
|
|
|
41 We call this a BELONGS TO relation. Because the relation is an infrastructure
|
|
|
42 built on top of the registers, you can still use them for something else,
|
|
|
43 like storing values.
|
|
|
44 </P>
|
|
|
45
|
|
|
46 <P>
|
|
|
47 As an example, consider the following binary tree in LISP notation:
|
|
|
48 ((1, (2, 3)), (4, ((5, 6), 7))). It looks awfully complicated for a seven
|
|
|
49 leaves data structure. To write that in CLC-INTERCAL one could do:
|
|
|
50 <PRE>
|
|
|
51 PLEASE DO .1 <- #1
|
|
|
52 DO ENSLAVE .1 TO .3
|
|
|
53 DO .2 <- #2
|
|
|
54 DO ENSLAVE .2 TO .4
|
|
|
55 PLEASE .5 <- #3
|
|
|
56 DO ENSLAVE .5 TO .4
|
|
|
57 DO ENSLAVE .4 TO .3
|
|
|
58 DO ENSLAVE .3 TO .6
|
|
|
59 PLEASE .7 <- #4
|
|
|
60 DO ENSLAVE .7 TO .8
|
|
|
61 DO .9 <- #5
|
|
|
62 DO ENSLAVE .9 TO .10
|
|
|
63 PLEASE .11 <- #6
|
|
|
64 DO ENSLAVE .11 TO .10
|
|
|
65 DO ENSLAVE .10 TO .12
|
|
|
66 DO .13 <- #7
|
|
|
67 PLEASE ENSLAVE .13 TO .12
|
|
|
68 DO ENSLAVE .12 TO .8
|
|
|
69 DO ENSLAVE .8 TO .6
|
|
|
70 </PRE>
|
|
|
71 </P>
|
|
|
72
|
|
|
73 <P>
|
|
|
74 The root of the tree is <CODE>.6</CODE>. Its two subtrees are <CODE>.3</CODE>
|
|
|
75 and <CODE>.8</CODE>. Down the left subtree, we note that both <CODE>.1</CODE>
|
|
|
76 and <CODE>.4</CODE> BELONG TO it. And so on, just as simple as the rest of
|
|
|
77 INTERCAL.
|
|
|
78 </P>
|
|
|
79
|
|
|
80 <P>
|
|
|
81 If you know the name of a slave, you can get to its master by prefixing the
|
|
|
82 name with a big-money symbol (<CODE>$</CODE>). If a register happens to
|
|
|
83 BELONG TO more than one master, the big-money symbol is the one most recently
|
|
|
84 acquired. The previous one is accessed with the prefix 2 (two), and the
|
|
|
85 one before it with the prefix 3 (three). Up to nine masters can be accessed
|
|
|
86 this way. For example, after:
|
|
|
87 <PRE>
|
|
|
88 PLEASE .1 <- #2
|
|
|
89 DO .2 <- #5
|
|
|
90 DO .3 <- #8
|
|
|
91 DO ENSLAVE .3 TO .2
|
|
|
92 DO ENSLAVE .3 TO .1
|
|
|
93 DO ENSLAVE .3 TO .3
|
|
|
94 </PRE>
|
|
|
95 The register <CODE>$.3</CODE> would be itself, while <CODE>2.3</CODE> would
|
|
|
96 be <CODE>.1</CODE> and <CODE>3.3</CODE> would be <CODE>.2</CODE>.
|
|
|
97 </P>
|
|
|
98
|
|
|
99 <P>
|
|
|
100 The prefix can be repeated to access the master's master, and so on. There is
|
|
|
101 no limit. If prefixes are repeated, they are executed from left to right.
|
|
|
102 Thus, in the above example, <CODE>$$2.3</CODE> would be the same as
|
|
|
103 <CODE>2.3</CODE> aka <CODE>.1</CODE> (because <CODE>$.3</CODE> is the same
|
|
|
104 as <CODE>.3</CODE>). On the other hand, <CODE>2$$.3</CODE> is an error,
|
|
|
105 because <CODE>2.3</CODE> is <CODE>.1</CODE>, which has no owner. Note that
|
|
|
106 this order of evaluation of prefixes differs from the way other languages
|
|
|
107 do that.
|
|
|
108 </P>
|
|
|
109
|
|
|
110 <P>
|
|
|
111 If you were wondering why CLC-INTERCAL has registers which cannot hold any
|
|
|
112 value (whirlpool, <CODE>@</CODE>), here's is why. They can be enslaved and
|
|
|
113 in turn can have slaves. So you can use them as indirect references to
|
|
|
114 other registers. In fact, this is what the lecture system does. See
|
|
|
115 <A HREF="lectures.html">the chapter on Classes and Lectures</A>.
|
|
|
116 </P>
|
|
|
117
|
|
|
118 <P>
|
|
|
119 One more note. When a register is STASHed, any information about its owners
|
|
|
120 is saved in the STASH. When it is retrieved, the ownership information comes
|
|
|
121 back from the STASH. Also, if you ENSLAVE or FREE a register which is being
|
|
|
122 IGNOREd nothing happens.
|
|
|
123 </P>
|
|
|
124
|
|
|
125 <P>
|
|
|
126 If you think to use this mechanism as pointers, you'll find out that you
|
|
|
127 very quickly run into problems. We won't tell you how, as it would spoil
|
|
|
128 the fun.
|
|
|
129 </P>
|
|
|
130
|
|
|
131 </BODY>
|
|
|
132 </HTML>
|
