Mercurial > repo
comparison interps/clc-intercal/CLC-INTERCAL-Docs-1.-94.-2/doc/html/belongs.html @ 996:859f9b4339e6
<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 <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> |