Mercurial > repo
diff 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 |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/interps/clc-intercal/CLC-INTERCAL-Docs-1.-94.-2/doc/html/belongs.html Sun Dec 09 19:30:08 2012 +0000 @@ -0,0 +1,132 @@ +<HTML> + <HEAD> + <TITLE>CLC-INTERCAL Reference</TITLE> + </HEAD> + <BODY> + <H1>CLC-INTERCAL Reference</H1> + <H2>... Belongs TO</H2> + + <P> + Table of contents: + <UL> + <LI><A HREF="index.html">Parent directory</A> + <LI><A HREF="#belongs">Belongs TO</A> + </UL> + </P> + + <H2><A NAME="belongs">Belongs To</A></H2> + + <P> + CLC-INTERCAL introduces an unique infrastructure over the registers. We + shall explain it with an example. + </P> + + <P> + Imagine building a tree structure in other languages. You have a root, and + there are pointers from the root to other nodes, which in turn have pointers + to other nodes, until you get to the leaves. + </P> + + <P> + This all sounds simple, but it has several drawbacks. The most important, + is that each node can have an arbitrary number of children, so you need to + start using messy techniques like variable-length lists. Also, if the + nodes need to contain values as well as pointers, you need to remember + reserving the extra space. + </P> + + <P> + CLC-INTERCAL does not suffer from these problems. By simply reversing the + pointers, you can easily see that any leave or node has exactly one parent. + We call this a BELONGS TO relation. Because the relation is an infrastructure + built on top of the registers, you can still use them for something else, + like storing values. + </P> + + <P> + As an example, consider the following binary tree in LISP notation: + ((1, (2, 3)), (4, ((5, 6), 7))). It looks awfully complicated for a seven + leaves data structure. To write that in CLC-INTERCAL one could do: +<PRE> + PLEASE DO .1 <- #1 + DO ENSLAVE .1 TO .3 + DO .2 <- #2 + DO ENSLAVE .2 TO .4 + PLEASE .5 <- #3 + DO ENSLAVE .5 TO .4 + DO ENSLAVE .4 TO .3 + DO ENSLAVE .3 TO .6 + PLEASE .7 <- #4 + DO ENSLAVE .7 TO .8 + DO .9 <- #5 + DO ENSLAVE .9 TO .10 + PLEASE .11 <- #6 + DO ENSLAVE .11 TO .10 + DO ENSLAVE .10 TO .12 + DO .13 <- #7 + PLEASE ENSLAVE .13 TO .12 + DO ENSLAVE .12 TO .8 + DO ENSLAVE .8 TO .6 +</PRE> + </P> + + <P> + The root of the tree is <CODE>.6</CODE>. Its two subtrees are <CODE>.3</CODE> + and <CODE>.8</CODE>. Down the left subtree, we note that both <CODE>.1</CODE> + and <CODE>.4</CODE> BELONG TO it. And so on, just as simple as the rest of + INTERCAL. + </P> + + <P> + If you know the name of a slave, you can get to its master by prefixing the + name with a big-money symbol (<CODE>$</CODE>). If a register happens to + BELONG TO more than one master, the big-money symbol is the one most recently + acquired. The previous one is accessed with the prefix 2 (two), and the + one before it with the prefix 3 (three). Up to nine masters can be accessed + this way. For example, after: +<PRE> + PLEASE .1 <- #2 + DO .2 <- #5 + DO .3 <- #8 + DO ENSLAVE .3 TO .2 + DO ENSLAVE .3 TO .1 + DO ENSLAVE .3 TO .3 +</PRE> + The register <CODE>$.3</CODE> would be itself, while <CODE>2.3</CODE> would + be <CODE>.1</CODE> and <CODE>3.3</CODE> would be <CODE>.2</CODE>. + </P> + + <P> + The prefix can be repeated to access the master's master, and so on. There is + no limit. If prefixes are repeated, they are executed from left to right. + Thus, in the above example, <CODE>$$2.3</CODE> would be the same as + <CODE>2.3</CODE> aka <CODE>.1</CODE> (because <CODE>$.3</CODE> is the same + as <CODE>.3</CODE>). On the other hand, <CODE>2$$.3</CODE> is an error, + because <CODE>2.3</CODE> is <CODE>.1</CODE>, which has no owner. Note that + this order of evaluation of prefixes differs from the way other languages + do that. + </P> + + <P> + If you were wondering why CLC-INTERCAL has registers which cannot hold any + value (whirlpool, <CODE>@</CODE>), here's is why. They can be enslaved and + in turn can have slaves. So you can use them as indirect references to + other registers. In fact, this is what the lecture system does. See + <A HREF="lectures.html">the chapter on Classes and Lectures</A>. + </P> + + <P> + One more note. When a register is STASHed, any information about its owners + is saved in the STASH. When it is retrieved, the ownership information comes + back from the STASH. Also, if you ENSLAVE or FREE a register which is being + IGNOREd nothing happens. + </P> + + <P> + If you think to use this mechanism as pointers, you'll find out that you + very quickly run into problems. We won't tell you how, as it would spoil + the fun. + </P> + +</BODY> +</HTML>