1) (ESR) INTERCAL would be intrinsically a crock even if it worked right.
-2) (LHH) The lexical analyzer is not completely independent of newlines.
- There is a conflict between the fact that newlines should be
- ignored almost everywhere, and the facts that the error mechanism
- wants to know about line numbers and the splat mechanism wants
- statements from the original program.
-
- The way these issues are currently resolved by the compiler is
- a bit over-complicated, but seems to work properly in almost
- every respect. I see only two problems: First, splat operation
- prints only the text line on which a typo was detected, not the
- whole statement. Second, for debugging purposes the text lines
- are printed as comments in the degenerated C code. These
- comments are only properly aligned with the degenerated code
- if the program has exactly one statement per line. (See
- pit/tests/testsplat.i for examples.)
-
- Neither of these problems is a big deal, which is why I haven't
- worried about them too much. The best solution I can see is
- to make "phase 1" of the lexer into a preprocessor able to
- correctly separate statements. It could then either add or
- remove newlines to put the program into one statement per line
- format, or put markers between statements for the main lexer
- to detect. Either way, it would be a good bit of work for a
- relatively small gain, and anyone trying it should make sure
- the result isn't buggier than the current version.
-
-3) (BLR) I have hacked up a fix to the problem with line numbers being off
+2) (BLR) I have hacked up a fix to the problem with line numbers being off
due to statements sharing/spanning lines. The parser now stores the
starting line number for all tuples, not just the splatted
ones. Not only does this give synchronized lines in the comments in
statement proper. So if a statement has its preamble on one line
and the rest of it on the next, the preamble will be beheaded.
- Still, it's a vast improvement, and as LHH points out, it's not
+ Still, it's a vast improvement, and as LHH pointed out, it's not
going to get much better without writing a preprocessing lexer that
can actually separate out the statements before any real parsing
begins. Until someone wants to do that, this will do nicely, I think.
statement, the last part will get truncated. Again, not a case we
want to be encouraging people to explore anyway.)
-4) (BLR) Interleave does not check the type of its arguments. The manual
+3) (BLR) Interleave does not check the type of its arguments. The manual
insinuates that interleaving 32-bit values should result in error 533;
instead, C-INTERCAL silently truncates them to 16 bits. Unfortunately,
the modified behavior of select's return type depends on this, so
there's not much we can do about it as things stand.
-5) (BLR) An array can't have sparks or ears in its subscript list after the
- first dimension. That is to say, this:
-
- DO ,1SUB'#1'#1 <- #0
-
- works fine, but this:
-
- DO ,1SUB#1'#1' <- #0
-
- doesn't parse, and gets treated as a syntax error (thus it is likely
- to be a problem with the grammar).
-
TO DO
1. (ESR) Add more optimization templates, esp. idioms for +, -, *, /.
NEW IN THIS RELEASE
- Release 0.21 (by Eric S. Raymond) 30 July 2002
+ Release 0.21 (by Eric S. Raymond)
1. Jonathan Nieder sent a grammar fix for BLR's old bug #5 (a bad spark-ears
interaction.)
Begin3
Title: intercal
-Version: 0.20
-Entered-date: 17SEP99
+Version: 0.21
+Entered-date: 30JUL2002
Description: An implementation of the language INTERCAL, legendary for
its perversity and horribleness (this version adds COME FROM
for extra flavor). Comes with language manual and examples
including possibly the entire extant body of INTERCAL code.
Now supports i18n and l14n (to Ancient Roman locale only)
Keywords: language, compiler, retrocomputing, geek humor
-Author: esr@snark.thyrsus.com (Eric S. Raymond)
-Maintained-by: esr@snark.thyrsus.com (Eric S. Raymond)
-Primary-site: locke.ccil.org /pub/esr
- 167K intercal-0.20.tar.gz
+Author: esr@thyrsus.com (Eric S. Raymond)
+Maintained-by: esr@thyrsus.com (Eric S. Raymond)
+Primary-site: http://www.tuxedo.org/~esr/intercal/
+ 167K intercal-0.21.tar.gz
Platforms: All
Copying-policy: GPL
End
+++ /dev/null
- BUGS
-
-There are still some known bugs in INTERCAL (and no doubt many we don't even
-suspect as yet). The following list accumulates current bug reports and
-TO DO agenda items through the current release.
-
-ESR = Eric S. Raymond
-SS = Steve Swales
-LHH = Louis Howell
-BLR = Brian Raiter
-
-1) (ESR) INTERCAL would be intrinsically a crock even if it worked right.
-
-2) (BLR) I have hacked up a fix to the problem with line numbers being off
- due to statements sharing/spanning lines. The parser now stores the
- starting line number for all tuples, not just the splatted
- ones. Not only does this give synchronized lines in the comments in
- the degenerated C code, but run-time error messages are just as
- reliable as the parse/compile-time ones. The line number in the
- error message is actually the line number of the next statement
- (e.g., if the next statement is on the same line, the line number
- of both statements will be used).
-
- Note that I said "just as reliable," as opposed to "fully
- reliable". Since the lexer doesn't know where the line ends until
- after it's already parsed the preamble (DO-PLEASE combo, line
- label, oh-oh-seven number, etc) of the following line, it actually
- stores as the starting line number the first non-whitespace of the
- statement proper. So if a statement has its preamble on one line
- and the rest of it on the next, the preamble will be beheaded.
-
- Still, it's a vast improvement, and as LHH pointed out, it's not
- going to get much better without writing a preprocessing lexer that
- can actually separate out the statements before any real parsing
- begins. Until someone wants to do that, this will do nicely, I think.
-
- As a side bonus, splatting now shows the entire statement. (Er,
- except when the statement both spans and shares a line. If a multi-
- line statement ends on the same line as the beginning of the next
- statement, the last part will get truncated. Again, not a case we
- want to be encouraging people to explore anyway.)
-
-3) (BLR) Interleave does not check the type of its arguments. The manual
- insinuates that interleaving 32-bit values should result in error 533;
- instead, C-INTERCAL silently truncates them to 16 bits. Unfortunately,
- the modified behavior of select's return type depends on this, so
- there's not much we can do about it as things stand.
-
- TO DO
-
-1. (ESR) Add more optimization templates, esp. idioms for +, -, *, /.
-
-2. (ESR) Forget this @!%$#! crock and take a long vacation.
BINDIR = /usr/bin
INCDIR = /usr/include/intercal
-LIBDIR = /usr/share/intercal
+SHAREDIR = /usr/share/intercal
+LIBDIR = /usr/share/intercal/lib
#INCDIR = $(PWD)
#LIBDIR = $(PWD)
DEBUG = -g -DDEBUG
# DEBUG = -O
-# This version (0.18) is POSIX-compliant. You should only set the POSIX
+# This version (from 0.18) is POSIX-compliant. You should only set the POSIX
# variable to null if you *need* to use the old <varargs.h> support;
# otherwise, the ANSI-compliant <stdarg.h> library will be used.
cp ick $(BINDIR)
-mkdir $(INCDIR)
cp lose.h abcess.h fiddle.h ick-wrap.c $(INCDIR)
+ -mkdir $(SHAREDIR)
+ (cd ../pit; cp *.i *.3i t_tet *.fft glider gun blinkers $(SHAREDIR))
-mkdir $(LIBDIR)
cp libick.a $(LIBDIR)
- (cd ../pit; cp *.i *.3i t_tet *.fft glider gun blinkers $(LIBDIR))
- -mkdir $(LIBDIR)/lib
- (cd ../pit/lib; cp *.*i $(LIBDIR)/lib)
+ (cd ../pit/lib; cp *.*i $(LIBDIR))
clean:
rm -f yacc.* y.tab.* y.output *~ *.[oa] lexer.c ick.c lextest ick
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
-<HTML>
-<HEAD>
-
-<TITLE>Abstraction and Modularity in INTERCAL</TITLE>
-
-
-</HEAD>
-<BODY BGCOLOR="#FFFFFF">
-<BR><BR><BR>
-<BLOCKQUOTE>
-<P><TT>
-<img src="notfunny.png" align=right alt="Not Funny!">
-Abstraction and Modularity in INTERCAL<br>
-D. Alexander Garrett<br>
-CS-538: Theory and Design of Programming Languages.<br clear=all>
-</TT></P>
-<P><TT>
-"<em>And remember, when you look into the pit, the pit looks back into
-you.</em>"<br>
- -- Anonymous INTERCAL hacker
-</TT></P>
-<P><TT>
-On May 26, 1972, two students at Princeton University took the
-programming community if not by storm, at least by mild sprinkle when
-they released INTERCAL[<A HREF="#note1">1</A>]. They were summarily
-dismissed from Princeton and forced to flee to a small banana republic
-where they refine the finer points of the language on political
-prisoners. This is, of course, strictly against the Geneva Convention,
-but as you will see, INTERCAL strives to be an unconventional
-language.
-</TT></P>
-<P><TT>
-Eighteen years later, while suffering from a paralytic attack of
-ennui, the Mad Malvernite J. Lapin perpetrated a hack of untold
-consequences upon the world by rereleasing INTERCAL under UN*X, which
-he renamed C-INTERCAL.\ 6 Unfortunately, J. Lapin appears to be a
-pseudonym, so nobody can determine upon whose shoulders the blame
-should rest for such malfeasance. However, some people suspect that
-the rerelease of INTERCAL heralds the time when the Old Ones shall
-wake from their sleep deep beneath the sea and shall rule over the
-earth for 2^32 years, befuddling men's minds and forcing them to use
-buggy overpriced software[<A href="#note2">2</A>].
-</TT></P>
-<P><TT>
-But I'm not here to talk about eschatology, I'm here to talk about
-modularity and abstraction. Well, believe me, you couldn't have
-designed a language more abstract than INTERCAL. To begin with, one of
-the most important aspects of abstraction is information
-hiding. Information hiding is a time honoured tradition of computer
-programmers, although sometimes it goes by its other name, "job
-security". The idea is to make your code as obscure as possible,
-hiding any possible information, so your employer couldn't fire you
-and hire some junior birdman mailboy to maintain your code. INTERCAL
-doesn't only hide information it actively distorts it. For example,
-the easiest way to store the value of 65536 in a 32-bit INTERCAL
-variable is: </TT></P>
-<BLOCKQUOTE><TT>DO:1<-#0$#256</TT></BLOCKQUOTE>
-<P><TT>
-If that's the easiest way, imagine the power at your fingertips if
-you're trying to be deliberately obscure! To further demonstrate, if
-you were to write a program in INTERCAL which reads in 32-bit unsigned
-integers, treats them as signed 2's complement numbers, and prints out
-their absolute values, it would take about 22 lines of code and
-between 15 and 30 minutes to write, whereas the same program could be
-written in a single line of SNOBOL or APL requiring about a minute to
-write both[<A HREF="#note3">3</A>]. So not only does INTERCAL allow
-the programmer to generate twenty times as much code as most other
-languages, making the programmer appear much more productive than his
-colleagues forced to program in a terse language, an INTERCAL program
-also takes much longer to write, allowing for more Quake-breaks. And
-as an added bonus, when the programmer is done, the information is so
-cleverly hidden that not even Sparky the Wonder Dog could find it, and
-she can find gravy in a cesspool! This allows the programmer to take
-even more Quake-breaks, as management doesn't dare fire such an
-important asset to the company.
-</TT></P>
-<P><TT>
-In addition to information hiding, multinational support is also an
-important part of abstraction. As information exchange causes the
-globe to shrink,[<A HREF="#note4">4</A>] it's important that
-programming languages are able to support a wide variety of different
-cultures. To that end, INTERCAL took the obvious step. Since the
-number systems of different countries are different from other
-different countries where the relationship between the different
-countries can be symmetric or transitive, it cannot, for obvious
-reasons, be reflexive, INTERCAL has implemented a different number
-system. Instead of using numerals, all input is done by typing in the
-name of the number. For example, if you wanted to feed the value of
-523 to an INTERCAL program, the input would look like "FIVE TWO
-THREE."[<A HREF="#note5">5</A>] Additionally, INTERCAL will also
-accept the value of OH for zero and NINER for 9. Recognising that
-INTERCAL would have multicultural scope, the implementors implemented
-number support for input digits in Sanskrit, Basque, Tagalog,
-Classical Nahuatl, Georgian, Kwakiutl, and Volapuk.
-</TT></P>
-<P><TT>
-Until the new INTERCAL compiler with better RYM[<A
-HREF="#note6">6</A>] access comes out, the old compiler has no way of
-knowing which language you are familiar with and thus it doesn't know
-what language to produce its output in[<A
-HREF="#note7">7</A>]. INTERCAL elegantly solves this problem by
-producing its output in Roman numerals, under the assumption that when
-Rome was at the height of its strength, half the world was under its
-dominion, so the comprehension of Roman numerals is part of our racial
-memory.
-</TT></P>
-<P><TT>
-In addition to being a versatile and truly international language,
-INTERCAL is also very simple. For example, in most languages the
-logical operators AND, OR, and XOR are binary, i.e., they require two
-operands to operate on. In INTERCAL, AND, OR, and XOR are unary
-operators, thereby halving the potential for pernicious logical
-errors. AND is represented by the ampersand (&), OR by the
-inverted, baseless isoceles triangle (V) and XOR by the what[<A
-HREF="#note8">8</A>] (?). The way the unary operators work is to
-perform the required operation on adjacent bits in the variable. Thus,
-#&77 (binary = 1001101) is binary 0000000000000100 = 4, #V77 is
-binary 1000000001101111 = 32879, and #?77 is binary 1000000001101011 =
-32875.[<A HREF="#note9">9</A>]
-</TT></P>
-<P><TT>
-Ever since Dijkstra's seminal paper "Use of GOTO Considered Harmful"
-was published in Communications of the ACM, there has been a hue and
-cry against the use of GOTO. INTERCAL recognises the importance of
-structured programming and rebukes the GOTO, saying <EM>retro me
-iad</EM>[<A HREF="#note10">10</A>]. In fact, the implementors of
-INTERCAL feel so strongly about the poor programming habits that GOTO
-encourages, that they implemented GOTO's opposite number, COME
-FROM. Thus if you had a program which looked similar to below:</TT></P>
-<BLOCKQUOTE><TT>
-(1) PLEASE <YOUR STATEMENT HERE><BR>
-</TT><BLOCKQUOTE>
-.<BR>
-.<BR>
-.
-</BLOCKQUOTE><TT>
-(2) DO COME FROM (1)
-</TT></BLOCKQUOTE>
-<P><TT>
-anytime the program executed the statement at label 1, it would
-immediately jump to the statement at label 2 without executing any of
-the intervening statements. This is very difficult to follow and
-requires considerable expertise to use correctly and makes the code
-almost impossible to follow. That's right, baby -- information hiding.
-</TT></P>
-<P><TT>
-One of the big changes to C that Stroustroup made when he created C++
-was the use of const data types, which kept the programmer from
-inadvertently changing the values of variables which shouldn't.[<A
-HREF="#note11">11</A>] The creators of INTERCAL recognised the need
-for this way before Stroustroup became Mr. Fancy Pants and so they put
-the IGNORE statement into the language. Any variables or arrays named
-in a list following the DO IGNORE directive will effectively become
-read-only. Their value can be used in operations and assigned to other
-variables, but any attempt to assign a value to a variable being
-IGNOREd will be met with a contempt so profound that the compiler will
-pass over it in utter silence. Of course, there may be a time when you
-want to cast away the constancy of variable, and in that case, you
-would use the REMEMBER directive. Any variable which is REMEMBERed
-will stay so until it is IGNORED. Future versions of the language may
-have a SNUB directive which when used upon a variable will cause it to
-IGNORE any attempts to write to it, even if it is REMEMBERed. The only
-way to make a SNUBbed variable writeable again is through the use of
-the APOLOGIZE statement which has roughly a fifty percent chance of
-working[<A HREF="#note12">12</A>]. The DON'T BE LIKE THAT. YOU REMIND
-ME OF MY MOTHER statement is currently a valid statement in INTERCAL
-though if used upon an IGNOREd variable will not cause a change of
-state in that variable, i.e., it will still be IGNOREd.[<A
-HREF="#note13">13</A>]
-</TT></P>
-<P><TT>
-INTERCAL is not even vaguely modular and nothing I can say would
-persuade you that it was.</TT></P>
-<P><TT> INTERCAL is a very dynamic, constantly
-evolving[<A HREF="#note14">14</A>] language which shows much promise
-for future generations of programmers. With languages like Visual
-Basic and Java out there which allow people who can hardly tie their
-shoes to write complicated GUI WWW browsers, people will begin to
-think that programmers aren't wizards and should be earning less than
-that nice young man at the local fast food joint who asks them if
-they'd like fries with that. Hmmm... as long as I have a couple of
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Abstraction and Modularity in INTERCAL</title>
+<style type="text/css">
+/*<![CDATA[*/
+ body {
+ background-color: #FFFFFF;
+ }
+ span.c1 {font-size: 80%}
+/*]]>*/
+</style>
+</head>
+<body>
+<br />
+<br />
+<br />
+<blockquote>
+<p><tt><img src="notfunny.png" align="right" alt="Not Funny!" />
+Abstraction and Modularity in INTERCAL<br />
+D. Alexander Garrett<br />
+CS-538: Theory and Design of Programming Languages.<br
+clear="all" />
+</tt></p>
+
+<p><tt>"<em>And remember, when you look into the pit, the pit looks
+back into you.</em>"<br />
+         -- Anonymous
+INTERCAL hacker</tt></p>
+
+<p><tt>On May 26, 1972, two students at Princeton University took
+the programming community if not by storm, at least by mild
+sprinkle when they released INTERCAL[<a href="#note1">1</a>]. They
+were summarily dismissed from Princeton and forced to flee to a
+small banana republic where they refine the finer points of the
+language on political prisoners. This is, of course, strictly
+against the Geneva Convention, but as you will see, INTERCAL
+strives to be an unconventional language.</tt></p>
+
+<p><tt>Eighteen years later, while suffering from a paralytic
+attack of ennui, the Mad Malvernite J. Lapin perpetrated a hack of
+untold consequences upon the world by rereleasing INTERCAL under
+UN*X, which he renamed C-INTERCAL. Unfortunately, J. Lapin appears
+to be a pseudonym, so nobody can determine upon whose shoulders the
+blame should rest for such malfeasance. However, some people
+suspect that the rerelease of INTERCAL heralds the time when the
+Old Ones shall wake from their sleep deep beneath the sea and shall
+rule over the earth for 2^32 years, befuddling men's minds and
+forcing them to use buggy overpriced software[<a
+href="#note2">2</a>].</tt></p>
+
+<p><tt>But I'm not here to talk about eschatology, I'm here to talk
+about modularity and abstraction. Well, believe me, you couldn't
+have designed a language more abstract than INTERCAL. To begin
+with, one of the most important aspects of abstraction is
+information hiding. Information hiding is a time honoured tradition
+of computer programmers, although sometimes it goes by its other
+name, "job security". The idea is to make your code as obscure as
+possible, hiding any possible information, so your employer
+couldn't fire you and hire some junior birdman mailboy to maintain
+your code. INTERCAL doesn't only hide information it actively
+distorts it. For example, the easiest way to store the value of
+65536 in a 32-bit INTERCAL variable is:</tt></p>
+
+<blockquote><tt>DO:1<-#0$#256</tt></blockquote>
+
+<p><tt>If that's the easiest way, imagine the power at your
+fingertips if you're trying to be deliberately obscure! To further
+demonstrate, if you were to write a program in INTERCAL which reads
+in 32-bit unsigned integers, treats them as signed 2's complement
+numbers, and prints out their absolute values, it would take about
+22 lines of code and between 15 and 30 minutes to write, whereas
+the same program could be written in a single line of SNOBOL or APL
+requiring about a minute to write both[<a href="#note3">3</a>]. So
+not only does INTERCAL allow the programmer to generate twenty
+times as much code as most other languages, making the programmer
+appear much more productive than his colleagues forced to program
+in a terse language, an INTERCAL program also takes much longer to
+write, allowing for more Quake-breaks. And as an added bonus, when
+the programmer is done, the information is so cleverly hidden that
+not even Sparky the Wonder Dog could find it, and she can find
+gravy in a cesspool! This allows the programmer to take even more
+Quake-breaks, as management doesn't dare fire such an important
+asset to the company.</tt></p>
+
+<p><tt>In addition to information hiding, multinational support is
+also an important part of abstraction. As information exchange
+causes the globe to shrink,[<a href="#note4">4</a>] it's important
+that programming languages are able to support a wide variety of
+different cultures. To that end, INTERCAL took the obvious step.
+Since the number systems of different countries are different from
+other different countries where the relationship between the
+different countries can be symmetric or transitive, it cannot, for
+obvious reasons, be reflexive, INTERCAL has implemented a different
+number system. Instead of using numerals, all input is done by
+typing in the name of the number. For example, if you wanted to
+feed the value of 523 to an INTERCAL program, the input would look
+like "FIVE TWO THREE."[<a href="#note5">5</a>] Additionally,
+INTERCAL will also accept the value of OH for zero and NINER for 9.
+Recognising that INTERCAL would have multicultural scope, the
+implementors implemented number support for input digits in
+Sanskrit, Basque, Tagalog, Classical Nahuatl, Georgian, Kwakiutl,
+and Volapuk.</tt></p>
+
+<p><tt>Until the new INTERCAL compiler with better RYM[<a
+href="#note6">6</a>] access comes out, the old compiler has no way
+of knowing which language you are familiar with and thus it doesn't
+know what language to produce its output in[<a
+href="#note7">7</a>]. INTERCAL elegantly solves this problem by
+producing its output in Roman numerals, under the assumption that
+when Rome was at the height of its strength, half the world was
+under its dominion, so the comprehension of Roman numerals is part
+of our racial memory.</tt></p>
+
+<p><tt>In addition to being a versatile and truly international
+language, INTERCAL is also very simple. For example, in most
+languages the logical operators AND, OR, and XOR are binary, i.e.,
+they require two operands to operate on. In INTERCAL, AND, OR, and
+XOR are unary operators, thereby halving the potential for
+pernicious logical errors. AND is represented by the ampersand
+(&), OR by the inverted, baseless isoceles triangle (V) and XOR
+by the what[<a href="#note8">8</a>] (?). The way the unary
+operators work is to perform the required operation on adjacent
+bits in the variable. Thus, #&77 (binary = 1001101) is binary
+0000000000000100 = 4, #V77 is binary 1000000001101111 = 32879, and
+#?77 is binary 1000000001101011 = 32875.[<a
+href="#note9">9</a>]</tt></p>
+
+<p><tt>Ever since Dijkstra's seminal paper "Use of GOTO Considered
+Harmful" was published in Communications of the ACM, there has been
+a hue and cry against the use of GOTO. INTERCAL recognises the
+importance of structured programming and rebukes the GOTO, saying
+<em>retro me iad</em>[<a href="#note10">10</a>]. In fact, the
+implementors of INTERCAL feel so strongly about the poor
+programming habits that GOTO encourages, that they implemented
+GOTO's opposite number, COME FROM. Thus if you had a program which
+looked similar to below:</tt></p>
+
+<blockquote><tt>(1) PLEASE <YOUR STATEMENT HERE><br />
+</tt>
+
+<blockquote>.<br />
+ .<br />
+ .</blockquote>
+
+<tt>(2) DO COME FROM (1)</tt></blockquote>
+
+<p><tt>anytime the program executed the statement at label 1, it
+would immediately jump to the statement at label 2 without
+executing any of the intervening statements. This is very difficult
+to follow and requires considerable expertise to use correctly and
+makes the code almost impossible to follow. That's right, baby --
+information hiding.</tt></p>
+
+<p><tt>One of the big changes to C that Stroustroup made when he
+created C++ was the use of const data types, which kept the
+programmer from inadvertently changing the values of variables
+which shouldn't.[<a href="#note11">11</a>] The creators of INTERCAL
+recognised the need for this way before Stroustroup became Mr.
+Fancy Pants and so they put the IGNORE statement into the language.
+Any variables or arrays named in a list following the DO IGNORE
+directive will effectively become read-only. Their value can be
+used in operations and assigned to other variables, but any attempt
+to assign a value to a variable being IGNOREd will be met with a
+contempt so profound that the compiler will pass over it in utter
+silence. Of course, there may be a time when you want to cast away
+the constancy of variable, and in that case, you would use the
+REMEMBER directive. Any variable which is REMEMBERed will stay so
+until it is IGNORED. Future versions of the language may have a
+SNUB directive which when used upon a variable will cause it to
+IGNORE any attempts to write to it, even if it is REMEMBERed. The
+only way to make a SNUBbed variable writeable again is through the
+use of the APOLOGIZE statement which has roughly a fifty percent
+chance of working[<a href="#note12">12</a>]. The DON'T BE LIKE
+THAT. YOU REMIND ME OF MY MOTHER statement is currently a valid
+statement in INTERCAL though if used upon an IGNOREd variable will
+not cause a change of state in that variable, i.e., it will still
+be IGNOREd.[<a href="#note13">13</a>]</tt></p>
+
+<p><tt>INTERCAL is not even vaguely modular and nothing I can say
+would persuade you that it was.</tt></p>
+
+<p><tt>INTERCAL is a very dynamic, constantly evolving[<a
+href="#note14">14</a>] language which shows much promise for future
+generations of programmers. With languages like Visual Basic and
+Java out there which allow people who can hardly tie their shoes to
+write complicated GUI WWW browsers, people will begin to think that
+programmers aren't wizards and should be earning less than that
+nice young man at the local fast food joint who asks them if they'd
+like fries with that. Hmmm... as long as I have a couple of
paragraphs left, I may as well mention that INTERCAL is fully
-portable, as the INTERCAL compiler first generates native C code and
-then compiles that. The INTERCAL compiler, itself, is written in C and
-is easily portable. There's even an INTERCAL major mode for emacs
-which will help you maintain the proper balance of PLEASE, DO, and
-PLEASE DO statements.[<A HREF="#note15">15</A>]
-</TT></P>
-<P><TT>
-References</TT><BR>
-<blockquote><TT>
-THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE MANUAL, Woods,
-Donald R. and Lyon, James M. Revised by Howell, Louis and Raymond, Eric S.
-<BR>
-My pineal gland.
-</TT></blockquote>
-<P><TT>
-Afterword</TT><BR>
-<blockquote><TT>
-The author of this paper is currently residing in a home for the
-criminally insane after attempting to rewrite the Linux kernel in Object
-Disoriented INTERCAL.
-</TT></blockquote>
-<br><br><br>
-<HR WIDTH="30%">
-<FONT SIZE=2><TT>
-[<A NAME="note1">1</A>] which stands for "Compiler Language With No Pronouncable Acronym", obviously.<BR>
-[<A NAME="note2">2</A>] There's a small sect of Billyites who, pointing to Microsoft, claim that this has already happened.<br>
-[<A NAME="note3">3</A>]These examples shamelessly cribbed from THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE MANUAL, page 2.<br>
-[<A NAME="note4">4</A>]It has been demonstrated that information exchange causes the release of a virtual particle called a metron. As the metron leaves the local system it was originally a part of, the system shrinks by an arbitrary amount which is directly proportional to the tightness of Tom Jones' pants. As more and more information is exchanged, an increasing number of metrons are released, and as Tom Jones' pants keep getting tighter and tighter, the local system, in this case, the planet, is shrinking without bound. What does this mean to you? Not much, really. Actually, I'm kind of sorry I brought it up. Just forget I mentioned it.<br>
-[<A NAME="note5">5</A>]It might also look different, depending on the font your terminal uses.<br>
-[<A NAME="note6">6</A>]Read Your Mind<br>
-[<A NAME="note7">7</A>]True, it could a) look at your input and produce output that matches the language or b) you could include compiler directives mandating an output language. Well, a) would require doubling the size of the system library which is definitely the Wrong Thing and b) would require adding more to the compiler which is definitely the Wrong Thing.<br>
-[<A NAME="note8">8</A>]Which due to the popularity of the movie, The Usual Suspects, may have its name changed to the "what the fuh", pending the creation of an ANSI committee to look into the matter, cubic cubits upon cubic cubits of jargonised deliberations interspersed with sheets of paper saying, "this page intensionally left blank", and at least one best selling pulp novelisation of the process written either by Jackie Collins or Donald Knuth (or both).<br>
-[<A NAME="note9">9</A>]You may be wondering about the splat (#) in front of each number. That's good. It shows that you have a curious mind. However, I'm not going to tell you what it means. That's called "information hiding".<br>
-[<A NAME="note10">10</A>]"get thee behind me, GOTO," obviously<br>
-[<A NAME="note11">11</A>]Somebody's law of programming seen on fortune: "Constants aren't; Variables don't."<br>
-[<A NAME="note12">12</A>]The surest way to get a SNUBbed variable to listen to you, again, is to offer it hot dogs without any buns. Hail Eris!<br>
-[<A NAME="note13">13</A>]Incidentally, INTERCAL is fully compliant with the military's view of female officers and supports the DON'T ASK, DON'T TELL ME YOU DON'T WANT IT, BABY statement.<br>
-[<A NAME="note14">14</A>]"constantly evolving" is a characteristic shared by most things that you put in a dark, cool place and pretend they don't exist, vide my refrigerator.<br>
-[<A NAME="note15">15</A>]Confused? Good. Information hiding.<br>
-
-
-</TT></font></BLOCKQUOTE>
-<BR><BR><BR>
-</BODY>
-</HTML>
+portable, as the INTERCAL compiler first generates native C code
+and then compiles that. The INTERCAL compiler, itself, is written
+in C and is easily portable. There's even an INTERCAL major mode
+for emacs which will help you maintain the proper balance of
+PLEASE, DO, and PLEASE DO statements.[<a
+href="#note15">15</a>]</tt></p>
+
+<p><tt>References</tt><br />
+</p>
+
+<blockquote><tt>THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE
+MANUAL, Woods, Donald R. and Lyon, James M. Revised by Howell,
+Louis and Raymond, Eric S.<br />
+ My pineal gland.</tt></blockquote>
+
+<p><tt>Afterword</tt><br />
+</p>
+
+<blockquote><tt>The author of this paper is currently residing in a
+home for the criminally insane after attempting to rewrite the
+Linux kernel in Object Disoriented INTERCAL.</tt></blockquote>
+
+<br />
+<br />
+<br />
+<hr width="30%" />
+<span class="c1"><tt>[<a id="note1" name="note1">1</a>] which
+stands for "Compiler Language With No Pronouncable Acronym",
+obviously.<br />
+[<a id="note2" name="note2">2</a>] There's a small sect of
+Billyites who, pointing to Microsoft, claim that this has already
+happened.<br />
+[<a id="note3" name="note3">3</a>]These examples shamelessly
+cribbed from THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE
+MANUAL, page 2.<br />
+[<a id="note4" name="note4">4</a>]It has been demonstrated that
+information exchange causes the release of a virtual particle
+called a metron. As the metron leaves the local system it was
+originally a part of, the system shrinks by an arbitrary amount
+which is directly proportional to the tightness of Tom Jones'
+pants. As more and more information is exchanged, an increasing
+number of metrons are released, and as Tom Jones' pants keep
+getting tighter and tighter, the local system, in this case, the
+planet, is shrinking without bound. What does this mean to you? Not
+much, really. Actually, I'm kind of sorry I brought it up. Just
+forget I mentioned it.<br />
+[<a id="note5" name="note5">5</a>]It might also look different,
+depending on the font your terminal uses.<br />
+[<a id="note6" name="note6">6</a>]Read Your Mind<br />
+[<a id="note7" name="note7">7</a>]True, it could a) look at your
+input and produce output that matches the language or b) you could
+include compiler directives mandating an output language. Well, a)
+would require doubling the size of the system library which is
+definitely the Wrong Thing and b) would require adding more to the
+compiler which is definitely the Wrong Thing.<br />
+[<a id="note8" name="note8">8</a>]Which due to the popularity of
+the movie, The Usual Suspects, may have its name changed to the
+"what the fuh", pending the creation of an ANSI committee to look
+into the matter, cubic cubits upon cubic cubits of jargonised
+deliberations interspersed with sheets of paper saying, "this page
+intensionally left blank", and at least one best selling pulp
+novelisation of the process written either by Jackie Collins or
+Donald Knuth (or both).<br />
+[<a id="note9" name="note9">9</a>]You may be wondering about the
+splat (#) in front of each number. That's good. It shows that you
+have a curious mind. However, I'm not going to tell you what it
+means. That's called "information hiding".<br />
+[<a id="note10" name="note10">10</a>]"get thee behind me, GOTO,"
+obviously<br />
+[<a id="note11" name="note11">11</a>]Somebody's law of programming
+seen on fortune: "Constants aren't; Variables don't."<br />
+[<a id="note12" name="note12">12</a>]The surest way to get a
+SNUBbed variable to listen to you, again, is to offer it hot dogs
+without any buns. Hail Eris!<br />
+[<a id="note13" name="note13">13</a>]Incidentally, INTERCAL is
+fully compliant with the military's view of female officers and
+supports the DON'T ASK, DON'T TELL ME YOU DON'T WANT IT, BABY
+statement.<br />
+[<a id="note14" name="note14">14</a>]"constantly evolving" is a
+characteristic shared by most things that you put in a dark, cool
+place and pretend they don't exist, vide my refrigerator.<br />
+[<a id="note15" name="note15">15</a>]Confused? Good. Information
+hiding.<br />
+</tt></span></blockquote>
+
+<br />
+<br />
+<br />
+</body>
+</html>
+
-<!doctype HTML PUBLIC "-//W3O//DTD W3 HTML 3.2//EN">
-<HTML>
-<HEAD>
-<link rev=made href=mailto:esr@snark.thyrsus.com>
-<meta name="description" content="Charlie Stross's article about INTERCAL">
-<meta name="keywords" content="humor, satire, parody">
-<TITLE>INTERCAL -- the Language From Hell</TITLE>
-</HEAD>
-<table width="100%" cellpadding=0 summary="Canned page header"><tr>
-<td width="30%">Back to <a href="index">Intercal Resources</a>
-<td width="30%"align=center>Up to <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2002-07-11 21:59:17 $
-</tr></table>
-<HR>
-
-<i>The following article appeared in Computer Shopper (the British magazine
-of that name, not the Ziff-Davis title) around September 1992.</i>
-
-<H1 ALIGN=CENTER>Intercal -- the Language From Hell</H1>
-
-<p><I>Where would we be without effective programming languages?</I></p>
-
-<p>Wait, don't turn the page; that was a rhetorical question. (The
-answer isn't: word-processing on slide rules.) Every once in a while
-it's worth thinking about the matter. Most of us (the lucky ones,
-that is) don't come within spitting distance of programming from one
-day to the next. Those who do, usually don't give any thought to
-them: it's time to write that function so do it, in C or Cobol or
-dBase whatever comes to hand. We don't waste time contemplating the
-deeper significance of the tools we use to do the job. But what would
-we do without well-designed, efficient programming languages? </p>
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<meta name="generator"
+content="HTML Tidy for Linux/x86 (vers 1st February 2002), see www.w3.org" />
+<link rev="made" href="mailto:esr@snark.thyrsus.com" />
+<meta name="description"
+content="Charlie Stross's article about INTERCAL" />
+<meta name="keywords" content="humor, satire, parody" />
+<title>INTERCAL -- the Language From Hell</title>
+<style type="text/css">
+/*<![CDATA[*/
+ p.c2 {font-style: italic}
+ h1.c1 {text-align: center}
+/*]]>*/
+</style>
+</head>
+<body>
+<table width="100%" cellpadding="0" summary="Canned page header">
+<tr>
+<td width="30%">Back to <a href="index">Intercal Resources</a></td>
+<td width="30%" align="center">Up to <a
+href="/~esr/sitemap.html">Site Map</a></td>
+<td width="30%" align="right">$Date: 2002-07-30 23:39:23 $</td>
+</tr>
+</table>
+
+<hr />
+<em>The following article appeared in Computer Shopper (the British
+magazine of that name, not the Ziff-Davis title) around September
+1992.</em>
+
+<h1 class="c1">Intercal -- the Language From Hell</h1>
+
+<p class="c2">Where would we be without effective programming
+languages?</p>
+
+<p>Wait, don't turn the page; that was a rhetorical question. (The
+answer isn't: word-processing on slide rules.) Every once in a
+while it's worth thinking about the matter. Most of us (the lucky
+ones, that is) don't come within spitting distance of programming
+from one day to the next. Those who do, usually don't give any
+thought to them: it's time to write that function so do it, in C or
+Cobol or dBase whatever comes to hand. We don't waste time
+contemplating the deeper significance of the tools we use to do the
+job. But what would we do without well-designed, efficient
+programming languages?</p>
<p>Go back to slide rules, maybe.</p>
-<p>A computer, in a very real sense, is its language. The processor
-speaks in a native tongue, its own machine code: unreadable by humans
-and next to impossible to program in, but nevertheless essential.
-It's the existence of this language which makes the computer such a
-general purpose tool; a hardware platform upon which we layer the
-abstractions, the virtual machines, of our operating systems. Which
-are, when you stop to think about it, simply a set of grammatically
-correct expressions in the computer's internal language. Take the
-humble 386 PC for example. Feed it one set of instructions and it
-pretends to be a cute little Windows machine; feed it another set, and
-something hairy happens -- it turns into a big, bad file server and
-starts demanding passwords and issuing threats. </p>
-
-<p>This flexibility is not an accident. Almost from the start, the
-feature which distinguished computers from their complex calculating
-predecessors was the fact that they were programmable -- indeed,
-universally programmable, capable of tackling any computationally
-tractable problem. Strip away the programmability of the machine and
-you lose the universality. Not to mention the usefulness.</p>
+<p>A computer, in a very real sense, is its language. The processor
+speaks in a native tongue, its own machine code: unreadable by
+humans and next to impossible to program in, but nevertheless
+essential. It's the existence of this language which makes the
+computer such a general purpose tool; a hardware platform upon
+which we layer the abstractions, the virtual machines, of our
+operating systems. Which are, when you stop to think about it,
+simply a set of grammatically correct expressions in the computer's
+internal language. Take the humble 386 PC for example. Feed it one
+set of instructions and it pretends to be a cute little Windows
+machine; feed it another set, and something hairy happens -- it
+turns into a big, bad file server and starts demanding passwords
+and issuing threats.</p>
+
+<p>This flexibility is not an accident. Almost from the start, the
+feature which distinguished computers from their complex
+calculating predecessors was the fact that they were programmable
+-- indeed, universally programmable, capable of tackling any
+computationally tractable problem. Strip away the programmability
+of the machine and you lose the universality. Not to mention the
+usefulness.</p>
<p>Programming languages, as any fule kno, originated in the
-nineteen-fifties as a partial solution to a major difficulty; machine
-code is difficult to write and maintain and next to impossible to move
-(or port) from one computer to another of a different type.
-Assemblers, which allowed the programmers to write machine code using
-relatively simple mnemonic commands (which were then "assembled" into
-machine code) were an early innovation, but still failed to address
-the portability issue. The solution that finally took off was the
-concept of an abstract "high level" language: and the first to achieve
-widespread use was Fortran.</p>
+nineteen-fifties as a partial solution to a major difficulty;
+machine code is difficult to write and maintain and next to
+impossible to move (or port) from one computer to another of a
+different type. Assemblers, which allowed the programmers to write
+machine code using relatively simple mnemonic commands (which were
+then "assembled" into machine code) were an early innovation, but
+still failed to address the portability issue. The solution that
+finally took off was the concept of an abstract "high level"
+language: and the first to achieve widespread use was Fortran.</p>
<p>A high level language is an artificial language with a rigidly
specified grammar, which can be translated into machine code via a
-program called a "compiler". Statements in the high level language
+program called a "compiler". Statements in the high level language
may correspond to individual statements, or whole series of
-statements, in the machine language ofthe computer. Indeed, the only
-thing that makes compilation practical is the fact that all computer
-language systems are effectively equivalent; any algorithm which can
-be expressed in one language can be solved in any other, in principle.
-So why are there so many languages?</p>
-
-<H2>A load of old cobol'ers</H2>
-
-<p>There are several answers to the question of language proliferation.
-Besides the facetious (some of us don't like Cobol) and the obvious
-(designing languages looks like a Fun Thing to a certain type of
-warped personality), there's the pragmatic reason. Simply put, some
-languages are excellent for expressing certain types of problem, but
-are lousy at dealing with other situations. Take Prolog, for example.
-Prolog is a brilliant language for resolving formal logic propositions
-expressable in the first order predicate calculus, but you'd need your
-head examining if you tried to write an operating system in it. (The
-Japanese MITI tried to do something similar with their Fifth
-Generation Project, and when was the last time you heard of them?
-Right.) Alternatively, take C. C is a wonderful language. It
-combines the flexibility and speed of raw machine code with the
-readability of ... er. Yes, you can re-jig a C compiler to run on
-anything. You can fine-tune it to produce tight, fast machine code
-that will execute on your toaster. Yes, you can write wonderful
-device drivers in it. But, again, you'd need your head examining if
-you set out to write a humongous database application in it. That's
-what Cobol is for; or SQL. So to the point of this article ...
-INTERCAL.</p>
-
-<H2>An icky mess</H2>
-
-<p>INTERCAL is a programming language which is to other languages as
-elephants are to deep-sea fishing -- it has nothing whatsoever to do
-with them. Nothing ... except that it's a programming language. And
-it serves as a wonderful example of the fact that, despite their
-theoretical, abstract interchangeability, not all languages are born
-equal. Here's a potted history of the offender:</p>
-
-<p>INTERCAL is short for "Computer Language With No Readily Pronouncable
-Acronym". It was not so much designed as perpetrated at Princeton
-University, on the morning of May 26th, 1972, by Donald R. Woods and
-James M. Lyon. They have been trying to live it down ever since.
-The current implementation, C-INTERCAL, was written by Eric S.
-Raymond (also the author of The New Hacker's Dictionary), and -- god
-help us -- runs on anything that supports C (and the C programming
-tools lex and yacc).</p>
-
-<p>INTERCAL is, in its own terms, elegant, simple and concise. It is
-also flexible and forgiving; if the compiler (called, appropriately
-enough, ick) encounters something it doesn't understand it simply
-ignores it and carries on. In order to insert a comment, just type in
-something that ick thinks is wrong; but be careful not to embed any
-valid INTERCAL code in your comments, or ick will get all excited and
-compile it. There are only two variable types: 16-bit integers, and
-32-bit integers, denoted by .1 (for the 16-bit variable called "1") or
-:1 (for the 32-bit variable named "1"); note that .1 is not equivalent
-to :1 and definitely has nothing to do with 0.1 (unless it happens to
-be storing a value of 0.1).</p>
-
-<p>INTERCAL supports two unique bitwise operators, interleave (or mingle)
-and select, denoted by the "^" and "~" symbols respectively. You
-interleave two variables by alternating the bits in the two operands;
-you select two variables by taking from the first operand whichever
-bits correspond to 1's in the second operand, then pack these bits to
-the right in the result. There are also numerous unary bitwise
-operators, and in order to resolve matters of precedence the pedantic
-may use sparks (') or rabbit-ears (") to group expressions (Don't
-blame me for the silly names: INTERCAL has a character set which is
-best described as creative.) It is not surprising that these operators
-are unique to INTERCAL; the parlous readability of C would not be
-enhanced by the addition of syntax like:</p>
-
-<p><TT>PLEASE DO IGNORE .1 <-".1^C'&:51~"#V1^C!12~;&75SUB"V'V.1~</TT></p>
-
-<p>Like any other language, INTERCAL has flow-of-control statements and
-input and output statements. To write something or other into a
-variable, you need the WRITE IN list statement, where list is a string
-of variables and/or array elements. The format of the input data
-should be as numbers, the digits of which are spelt out in english in
-the range ZERO (or OH) to FOUR TWO NINE FOUR NINE SIX SEVEN TWO NINE
-FIVE. To output some information, you need the READ OUT list
-statement, where list again consists of variables. Numbers are
-printed, by default, in the form of "extended" Roman numerals (the
-syntax of which I will draw a merciful veil over), although the
-scholarly may make use of the standard library, which contains
+statements, in the machine language ofthe computer. Indeed, the
+only thing that makes compilation practical is the fact that all
+computer language systems are effectively equivalent; any algorithm
+which can be expressed in one language can be solved in any other,
+in principle. So why are there so many languages?</p>
+
+<h2>A load of old cobol'ers</h2>
+
+<p>There are several answers to the question of language
+proliferation. Besides the facetious (some of us don't like Cobol)
+and the obvious (designing languages looks like a Fun Thing to a
+certain type of warped personality), there's the pragmatic reason.
+Simply put, some languages are excellent for expressing certain
+types of problem, but are lousy at dealing with other situations.
+Take Prolog, for example. Prolog is a brilliant language for
+resolving formal logic propositions expressable in the first order
+predicate calculus, but you'd need your head examining if you tried
+to write an operating system in it. (The Japanese MITI tried to do
+something similar with their Fifth Generation Project, and when was
+the last time you heard of them? Right.) Alternatively, take C. C
+is a wonderful language. It combines the flexibility and speed of
+raw machine code with the readability of ... er. Yes, you can
+re-jig a C compiler to run on anything. You can fine-tune it to
+produce tight, fast machine code that will execute on your toaster.
+Yes, you can write wonderful device drivers in it. But, again,
+you'd need your head examining if you set out to write a humongous
+database application in it. That's what Cobol is for; or SQL. So to
+the point of this article ... INTERCAL.</p>
+
+<h2>An icky mess</h2>
+
+<p>INTERCAL is a programming language which is to other languages
+as elephants are to deep-sea fishing -- it has nothing whatsoever
+to do with them. Nothing ... except that it's a programming
+language. And it serves as a wonderful example of the fact that,
+despite their theoretical, abstract interchangeability, not all
+languages are born equal. Here's a potted history of the
+offender:</p>
+
+<p>INTERCAL is short for "Computer Language With No Readily
+Pronouncable Acronym". It was not so much designed as perpetrated
+at Princeton University, on the morning of May 26th, 1972, by
+Donald R. Woods and James M. Lyon. They have been trying to live it
+down ever since. The current implementation, C-INTERCAL, was
+written by Eric S. Raymond (also the author of The New Hacker's
+Dictionary), and -- god help us -- runs on anything that supports C
+(and the C programming tools lex and yacc).</p>
+
+<p>INTERCAL is, in its own terms, elegant, simple and concise. It
+is also flexible and forgiving; if the compiler (called,
+appropriately enough, ick) encounters something it doesn't
+understand it simply ignores it and carries on. In order to insert
+a comment, just type in something that ick thinks is wrong; but be
+careful not to embed any valid INTERCAL code in your comments, or
+ick will get all excited and compile it. There are only two
+variable types: 16-bit integers, and 32-bit integers, denoted by .1
+(for the 16-bit variable called "1") or :1 (for the 32-bit variable
+named "1"); note that .1 is not equivalent to :1 and definitely has
+nothing to do with 0.1 (unless it happens to be storing a value of
+0.1).</p>
+
+<p>INTERCAL supports two unique bitwise operators, interleave (or
+mingle) and select, denoted by the "^" and "~" symbols
+respectively. You interleave two variables by alternating the bits
+in the two operands; you select two variables by taking from the
+first operand whichever bits correspond to 1's in the second
+operand, then pack these bits to the right in the result. There are
+also numerous unary bitwise operators, and in order to resolve
+matters of precedence the pedantic may use sparks (') or
+rabbit-ears (") to group expressions (Don't blame me for the silly
+names: INTERCAL has a character set which is best described as
+creative.) It is not surprising that these operators are unique to
+INTERCAL; the parlous readability of C would not be enhanced by the
+addition of syntax like:</p>
+
+<p><tt>PLEASE DO IGNORE .1
+<-".1^C'&:51~"#V1^C!12~;&75SUB"V'V.1~</tt></p>
+
+<p>Like any other language, INTERCAL has flow-of-control statements
+and input and output statements. To write something or other into a
+variable, you need the WRITE IN list statement, where list is a
+string of variables and/or array elements. The format of the input
+data should be as numbers, the digits of which are spelt out in
+english in the range ZERO (or OH) to FOUR TWO NINE FOUR NINE SIX
+SEVEN TWO NINE FIVE. To output some information, you need the READ
+OUT list statement, where list again consists of variables. Numbers
+are printed, by default, in the form of "extended" Roman numerals
+(the syntax of which I will draw a merciful veil over), although
+the scholarly may make use of the standard library, which contains
routines for formatting output in Sanskrit.</p>
-<p>Like FORTRAN, INTERCAL uses line numbers which are optional and follow
-in no particular order. Unlike FORTRAN, INTERCAL has no evil,
-unspeakable GOTO command, and not even an IF statement. However, you
-would be wrong to ascribe this to INTERCAL being designed for
-structured programming; it is actually because C-INTERCAL is the only
-known language that implements the legendary COME FROM ... control
-statement (originally described by R. L. Clark in "A Linguistic
-contribution to GOTO-less programming", Comm. ACM 27 (1984), pp.
-349-350). For many years the GOTO statement -- once the primary means
-of controlling the sequence of execution of a program -- has been
-reviled as contributing to unreadable, unpredictable code that is
-virtually impossible to follow because it jumps about the place like a
-kangaroo on amphetamines. The COME FROM statement enables INTERCAL to
-do away with nasty GOTO's, while still preserving for the programmer
-that sense of warm self-esteem and achievement that comes from
+<p>Like FORTRAN, INTERCAL uses line numbers which are optional and
+follow in no particular order. Unlike FORTRAN, INTERCAL has no
+evil, unspeakable GOTO command, and not even an IF statement.
+However, you would be wrong to ascribe this to INTERCAL being
+designed for structured programming; it is actually because
+C-INTERCAL is the only known language that implements the legendary
+COME FROM ... control statement (originally described by R. L.
+Clark in "A Linguistic contribution to GOTO-less programming",
+Comm. ACM 27 (1984), pp. 349-350). For many years the GOTO
+statement -- once the primary means of controlling the sequence of
+execution of a program -- has been reviled as contributing to
+unreadable, unpredictable code that is virtually impossible to
+follow because it jumps about the place like a kangaroo on
+amphetamines. The COME FROM statement enables INTERCAL to do away
+with nasty GOTO's, while still preserving for the programmer that
+sense of warm self-esteem and achievement that comes from
successfully writing a really nasty piece of self-modifying code
-involving computed GOTO's in FORTRAN (Or, for the terminally hip and
-hacker-ish, involving a triple-indirect pointer to a union of UNIX
-kernel data structures in C. Capisce?) Basically, the COME FROM
-statement specifies a line, or lines, which -- when the program
-executes them -- will jump to the COME FROM: effectively the opposite
-of GOTO.</p>
-
-<p>Because INTERCAL contains no equivalent of the NEXT statement for
-controlling whether or not some statement is executed, it provides a
-creative, endearing and unique substitute; abstention. For example, you
-can abstain from executing a given line of code with the ABSTAIN FROM
-(label) form of the command. Alternatively, and more uselessly, you can
-abstain from executing all statements of a specified type; for example, you
-can say</p>
-
-<p><TT>PLEASE ABSTAIN FROM IGNORING + FORGETTING</TT></p>
+involving computed GOTO's in FORTRAN (Or, for the terminally hip
+and hacker-ish, involving a triple-indirect pointer to a union of
+UNIX kernel data structures in C. Capisce?) Basically, the COME
+FROM statement specifies a line, or lines, which -- when the
+program executes them -- will jump to the COME FROM: effectively
+the opposite of GOTO.</p>
+
+<p>Because INTERCAL contains no equivalent of the NEXT statement
+for controlling whether or not some statement is executed, it
+provides a creative, endearing and unique substitute; abstention.
+For example, you can abstain from executing a given line of code
+with the ABSTAIN FROM (label) form of the command. Alternatively,
+and more uselessly, you can abstain from executing all statements
+of a specified type; for example, you can say</p>
+
+<p><tt>PLEASE ABSTAIN FROM IGNORING + FORGETTING</tt></p>
+
<p>or</p>
-<p><TT>DO ABSTAIN FROM ABSTAINING</TT></p>
+<p><tt>DO ABSTAIN FROM ABSTAINING</tt></p>
-<p>The abstention command is revoked by the REINSTATE statement. It is
-a Bad Idea to ABSTAIN FROM REINSTATING. It is also worth noting that
-the ABSTAIN syntax is rather confusing; for example, DO ABSTAIN FROM
-GIVING UP is not accepted, although a valid synonym for this is DON'T
-GIVE UP. (GIVE UP is the statement that terminates execution of a
-program. You are encouraged to use this statement at every
-opportunity. It is your only hope of escape.)</p>
+<p>The abstention command is revoked by the REINSTATE statement. It
+is a Bad Idea to ABSTAIN FROM REINSTATING. It is also worth noting
+that the ABSTAIN syntax is rather confusing; for example, DO
+ABSTAIN FROM GIVING UP is not accepted, although a valid synonym
+for this is DON'T GIVE UP. (GIVE UP is the statement that
+terminates execution of a program. You are encouraged to use this
+statement at every opportunity. It is your only hope of
+escape.)</p>
<p>The designers of the INTERCAL language believed that source code
-should be easy to understand or, failing that, friendly; in extremis,
-good old-fashioned politeness will do. Consequently, the syntax of
-the language looks a bit odd at first. After the line label (if any)
-there should be a statement identifier; this can be one of DO, PLEASE,
-or PLEASE DO. Programs which are insufficiently polite to the
-compiler may be rejected with the error message PROGRAMMER IS
-INSUFFICIENTLY POLITE; likewise, programs which spend too much time
-grovelling to the compiler will be terminated with extreme
-prejudice. The DO, PLEASE or PLEASE DO is then followed by
+should be easy to understand or, failing that, friendly; in
+extremis, good old-fashioned politeness will do. Consequently, the
+syntax of the language looks a bit odd at first. After the line
+label (if any) there should be a statement identifier; this can be
+one of DO, PLEASE, or PLEASE DO. Programs which are insufficiently
+polite to the compiler may be rejected with the error message
+PROGRAMMER IS INSUFFICIENTLY POLITE; likewise, programs which spend
+too much time grovelling to the compiler will be terminated with
+extreme prejudice. The DO, PLEASE or PLEASE DO is then followed by
(optionally) one of NOT, N'T, or %n, then a statement: the NOT or
N'T's meaning should be self-evident, while the %n is merely the
percentage probability that the following statement will be
executed.</p>
<p>Of course, with only two binary and three unary operators, it is
-rather difficult for programmers to get to grips with the
-language. Therefore, in a fit of quite uncharacteristic generosity,
-the designers have supplied -- and even partially documented -- a
+rather difficult for programmers to get to grips with the language.
+Therefore, in a fit of quite uncharacteristic generosity, the
+designers have supplied -- and even partially documented -- a
library of rather outre subroutines that carry out such esoteric
operations as addition, subtraction, logical comparison, and
generation of random numbers. The subroutines will be charmingly
-familiar to those PDP-11 assembly-language hackers among you who are
-also fluent in FORTRAN and SPITBOL.</p>
-
-<H2>Why you should program in Intercal</H2>
-
-<p>INTERCAL, despite being afflicted with these unique features (which,
-arguably, should remain that way) has survived for twenty years and is
-indeed thriving. The relatively recent C-INTERCAL dialect (which
-introduced the COME FROM statement, among other things) has spread it
-far beyond its original domain; the infamy continues, transmitted like
-a malign influence across the Internet. It is a matter of record that
-no computer language has ever succeeded in gaining widespread
-acceptance on the basis of elegance, comprehensibility or
-necessity. Look at FORTRAN, Cobol or C; all of them spread despite the
-fact that better alternatives were available. In fact, there are
-reasons to believe that INTERCAL is the language of the future.</p>
+familiar to those PDP-11 assembly-language hackers among you who
+are also fluent in FORTRAN and SPITBOL.</p>
+
+<h2>Why you should program in Intercal</h2>
+
+<p>INTERCAL, despite being afflicted with these unique features
+(which, arguably, should remain that way) has survived for twenty
+years and is indeed thriving. The relatively recent C-INTERCAL
+dialect (which introduced the COME FROM statement, among other
+things) has spread it far beyond its original domain; the infamy
+continues, transmitted like a malign influence across the Internet.
+It is a matter of record that no computer language has ever
+succeeded in gaining widespread acceptance on the basis of
+elegance, comprehensibility or necessity. Look at FORTRAN, Cobol or
+C; all of them spread despite the fact that better alternatives
+were available. In fact, there are reasons to believe that INTERCAL
+is the language of the future.</p>
<p>Firstly, INTERCAL creates jobs. Yes, it's true. In general, if a
particular programming tool is unfriendly, ugly, and absolutely
-essential, the response of management is to throw more programmers at
-it instead of replacing it. INTERCAL is so monumentally difficult to
-use for anything sensible that it is surely destined to be the cause
-of full employment, massive increases in the DP budget of every
-company where it is used, and general prosperity for programmers.</p>
+essential, the response of management is to throw more programmers
+at it instead of replacing it. INTERCAL is so monumentally
+difficult to use for anything sensible that it is surely destined
+to be the cause of full employment, massive increases in the DP
+budget of every company where it is used, and general prosperity
+for programmers.</p>
<p>Secondly, once you have learned INTERCAL you will be able to win
-friends and influence people. As the authors point out, if you were to
-state that the simplest way to store a value of 65536 in a 32-bit
-variable is</p>
-
-<p><TT>DO :1 <- #0$#256</TT></p>
-
-<p>any sensible programmer would say that this was absurd. Since this is
-indeed the simplest way of doing this, they'd be made to look like a
-fool in front of their boss (who, by Murphy's law, would have turned
-up at just that moment). This will have a devastating effect on their
-ego and simultaneously make you look brilliant (until they realise
-that you cribbed this example from the manual, like me. Deep shame.)</p>
-
-<p>Thirdly, INTERCAL helps sell hardware. There's been a lot of fuss
-recently about big corporations inventing gigantic, bloated windowing
-and operating systems that require monstrously powerful computers to
-run on; some cynics suggest that this is because personal computers
-are now so powerful that they can already do anything any reasonable
-individual would want them to, and it's necessary to invent warm furry
-buttons that soak up millions of processor cycles in order to sell new
-equipment. With INTERCAL, you no longer need Windows or OS/2 to slow
-your 486 PC to a crawl! A Sieve of Eratosthenes benchmark (that
-computes all the prime numbers less than 65536), when coded in
-INTERCAL, clocked over seventeen hours on a SPARCStation-1. The same
-program, in C, took less than 0.5 seconds -- thus proving, quite
-clearly, that INTERCAL software is so slow that you absolutely must
-buy a CRAY-3 or equivalent in order to have any hope of getting any
-work out of it.</p>
+friends and influence people. As the authors point out, if you were
+to state that the simplest way to store a value of 65536 in a
+32-bit variable is</p>
+
+<p><tt>DO :1 <- #0$#256</tt></p>
+
+<p>any sensible programmer would say that this was absurd. Since
+this is indeed the simplest way of doing this, they'd be made to
+look like a fool in front of their boss (who, by Murphy's law,
+would have turned up at just that moment). This will have a
+devastating effect on their ego and simultaneously make you look
+brilliant (until they realise that you cribbed this example from
+the manual, like me. Deep shame.)</p>
+
+<p>Thirdly, INTERCAL helps sell hardware. There's been a lot of
+fuss recently about big corporations inventing gigantic, bloated
+windowing and operating systems that require monstrously powerful
+computers to run on; some cynics suggest that this is because
+personal computers are now so powerful that they can already do
+anything any reasonable individual would want them to, and it's
+necessary to invent warm furry buttons that soak up millions of
+processor cycles in order to sell new equipment. With INTERCAL, you
+no longer need Windows or OS/2 to slow your 486 PC to a crawl! A
+Sieve of Eratosthenes benchmark (that computes all the prime
+numbers less than 65536), when coded in INTERCAL, clocked over
+seventeen hours on a SPARCStation-1. The same program, in C, took
+less than 0.5 seconds -- thus proving, quite clearly, that INTERCAL
+software is so slow that you absolutely must buy a CRAY-3 or
+equivalent in order to have any hope of getting any work out of
+it.</p>
<p>Consequently, it is quite clear that INTERCAL represents a major
-alternative to conventional programming languages. Anyone who learns
-this language is going to go far -- at least as far as the nearest
-psychiatric institution. Rumour has it that INTERCAL was not entirely
-unrelated to the collapse of the Soviet Union and the success of the
-Apollo missions. It is even reported to improve your sex life and
-restore hair loss! So we warmly advise you to take this utterly
-unbiased report at face value and go forth and get your friendly
-neighbourhood software company to switch to INTERCAL, wherever or
-whatever they may be using right now. You know it makes sense ...</p>
-
-<HR>
-<table width="100%" cellpadding=0 summary="Canned page footer"><tr>
-<td width="30%">Back to <a href="index">Intercal Resources</a>
-<td width="30%"align=center>Up to <a href="/~esr/sitemap.html">Site Map</a>
-<td width="30%" align=right>$Date: 2002-07-11 21:59:17 $
-</tr></table>
-
-<br clear="left">
-<ADDRESS>Eric S. Raymond <A HREF="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></A></ADDRESS>
-</BODY>
-</HTML>
+alternative to conventional programming languages. Anyone who
+learns this language is going to go far -- at least as far as the
+nearest psychiatric institution. Rumour has it that INTERCAL was
+not entirely unrelated to the collapse of the Soviet Union and the
+success of the Apollo missions. It is even reported to improve your
+sex life and restore hair loss! So we warmly advise you to take
+this utterly unbiased report at face value and go forth and get
+your friendly neighbourhood software company to switch to INTERCAL,
+wherever or whatever they may be using right now. You know it makes
+sense ...</p>
+
+<hr />
+<table width="100%" cellpadding="0" summary="Canned page footer">
+<tr>
+<td width="30%">Back to <a href="index">Intercal Resources</a></td>
+<td width="30%" align="center">Up to <a
+href="/~esr/sitemap.html">Site Map</a></td>
+<td width="30%" align="right">$Date: 2002-07-30 23:39:23 $</td>
+</tr>
+</table>
+
+<br clear="left" />
+<address>Eric S. Raymond <a
+href="mailto:esr@thyrsus.com"><esr@snark.thyrsus.com></a></address>
+</body>
+</html>