Mercurial > repo

<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 &lt;- #1
        DO ENSLAVE .1 TO .3
        DO .2 &lt;- #2
        DO ENSLAVE .2 TO .4
        PLEASE .5 &lt;- #3
        DO ENSLAVE .5 TO .4
        DO ENSLAVE .4 TO .3
        DO ENSLAVE .3 TO .6
        PLEASE .7 &lt;- #4
        DO ENSLAVE .7 TO .8
        DO .9 &lt;- #5
        DO ENSLAVE .9 TO .10
        PLEASE .11 &lt;- #6
        DO ENSLAVE .11 TO .10
        DO ENSLAVE .10 TO .12
        DO .13 &lt;- #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 &lt;- #2
	DO .2 &lt;- #5
	DO .3 &lt;- #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>
author	HackBot
date	Sun, 25 Sep 2016 20:17:31 +0000
parents	859f9b4339e6
children