From: Eric S. Raymond Date: Thu, 26 Aug 2010 01:34:19 +0000 (-0400) Subject: First re-merge commit: update README, add REPO-README and website files. X-Git-Tag: 0.29~128 X-Git-Url: http://thyrsus.com/gitweb/?a=commitdiff_plain;h=65728afce7df36daa72777d9962763b2f7e5c4c7;p=intercal.git First re-merge commit: update README, add REPO-README and website files. --- diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..7e930e9 --- /dev/null +++ b/.gitignore @@ -0,0 +1,19 @@ +*.o +*.a +*~ +Makefile +autom4te.cache/ +config.h +config.log +config.status +stamp-h1 +.deps +# Executables produced by standard build +bin2c +convickt +ick +oil +# Other generated stuff +ick.c +lexer.c +doc/*info* diff --git a/README b/README index fdc4196..4dcade9 100644 --- a/README +++ b/README @@ -2,9 +2,9 @@ DISCREDITS -This package is an implementation of the language INTERCAL designed by Don -Woods and James Lyon, who have since spent more than twenty years trying to -live it down. +This package is an implementation of the language INTERCAL designed by +Don Woods and James Lyon, who have since spent decades trying to live +it down. This implementation was created by Eric S. Raymond during a fit of lunacy from which he has since mostly recovered. It has been @@ -144,22 +144,10 @@ use it... the default is -wimpmode (i.e. NOT wimp mode)." SPREADING THE BLAME -There is an INTERCAL Resource Page at http://www.catb.org/intercal - -The latest version of INTERCAL is also kept available at the Retrocomputing -Museun, http://www.catb.org/retro. - -(The above two paragraphs are somewhat out of date, but I kept them there, -including the typos, for historical purposes. Looking through the -alt.lang.intercal archives is usually the best way to find out what the latest -version of C-INTERCAL (and you'll find out how to get its rival too, for that -matter) is nowadays; they tend to pop up in various unusual places, so giving -a URL might be misleading. Note also that contact details, and even who to -contact, often end up out of date; the newsgroup is also a good way to find -out who to contact. - -As of when I wrote this, the current homepage for C-INTERCAL and CLC-INTERCAL -is http://intercal.freeshell.org.) +There is an INTERCAL Resource Page at http://www.catb.org/intercal, and +another at http://intercal.freeshell.org. Both point at the same C-INTERCAL +repository, which lives at git://gitorious.org/intercal/intercal.git; +the freeshell page also distributes CLC-INTERCAL, a variant implementation. There is, in addition, an occasionally active USENET newsgroup devoted to the language: alt.lang.intercal. (It is a somewhat unusual newsgroup, as although diff --git a/REPO-README b/REPO-README new file mode 100644 index 0000000..2a64922 --- /dev/null +++ b/REPO-README @@ -0,0 +1,46 @@ +This is a multibranch repository that captures as much as we can find +and reconstruct of the history of C-INTERCAL. The history is not complete +because the project (begun in 1990) predates systematic use of version +control (and, indeed, any but the most primitive version-control systems). + +This repository stitches together some early RCS history up to 2003 +kept by Eric S. Raymond (esr), a large collection of release tarballs, and +some snapshots and darcs history after 2003 kept by Alex Smith (ais523). + +The main branch begins with the first public release, 0.3, from 1990. +Then it includes 0.5, 0.12, 0.13 and all of esr's mainline work up +to 0.24 in 2003. The main branch continues with ais523's 0.25 +and later releases until 2010. After the release 29 beta, the +main branch is esr's and ais523's merged code. + +The resolution of preserved history between releases varies a great +deal. In the original mainline, esr gradually began putting the +project under RCS control in mid-1996, just before 0.14. All changes +in the website directory were being tracked between about 0.18 and +0.24, but some source files had not yet been RCSed. Development from +0.24 through 0.28 is recorded only by public release tarballs and +sporadic backups. Development after 0.28 to the 0.29 beta and after +that until the creation of this unified repo was recorded in a darcs +archive. + +In August 2010 esr stitched all this information together into a +unified repository, which you are looking at now. Metainformation +such as commit dates and authorship has been preserved. Both esr and +ais23 will be using this repository as a basis for further development. + +There is a 'dos' branch that holds William W. Patterson's DOS port of 0.15. + +There is a 'thick' branch that contains Malcolm Ryan's Threaded +INTERCAL version forked from 0.17. The language extensions in Threaded +INTERCAL were merged into the mainline after 0.24, so the thick code +itself is only of historical interest. + +We are missing early mainline releases 0.4, 0.6-0.11, and 0.14; so +far, diligent searches of even the mustiest web and FTP archives have +failed to turn these up. If you can supply these, please inform the +maintainers. + + Eric S. Raymond + Alex Smith + August 2010 + diff --git a/website/index.html b/website/index.html new file mode 100644 index 0000000..9bc3f94 --- /dev/null +++ b/website/index.html @@ -0,0 +1,201 @@ + + + + + + + + + +The INTERCAL Resources Page + + + + + + + +
+ +

Beware! If you aren't a hard-core hacker, you'd best surf right +back where you came from now. Nothing but twisted +technical yuks and an inexorable descent into brain-sucking +obsession awaits beyond this point. You have been +warned.

+ +

Abandon All Sanity, Ye Who Enter Here

+ +

So, you think you've seen it all, eh?

+ +

OK. You've coded in C. You've hacked in LISP. Fortran and BASIC +hold no terrors for you. You write Emacs modes for fun. You eat +assemblers for breakfast. You're fluent in half a dozen languages +nobody but a handful of übergeeks have ever heard of. You grok +TECO. Possibly you even know <shudder> COBOL.

+ +

Maybe you're ready for the ultimate challenge...INTERCAL.

+ +

INTERCAL. The language designed to be Turing-complete but as +fundamentally unlike any existing language as possible. Expressions +that look like line noise. Control constructs that will make you +gasp, make you laugh, and possibly make you hurl. Data structures? +We don't need no steenking data structures!

+ +

INTERCAL. Designed very early one May morning in 1972 by two +hackers who are still trying to live it down. Initially implemented +on an IBM 360 running batch SPITBOL. Described by a manual that +circulated for years after the short life of the first +implementation, reducing strong men to tears (of laughter). Revived +in 1990 by the C-INTERCAL compiler, and now the center of an +international community of technomasochists.

+ +

INTERCAL. Now you, too, can be a part of the madness.

+ +

(Read what Ted Nelson had to say...)

+ +

INTERCAL Resources

+ +

Documentation

+ +

You can download either a Postscript or flat +text version of the Revised INTERCAL Manual here. Postscript is +recommended, as the manual now includes figures and diagrams until +recently unseen by any but the small handful with paper copies.

+ +

Source Code

+ +

The INTERCAL codebase is available for git cloning at: + +

git://gitorious.org/intercal/intercal.git

+ +

Requires either bison or yacc and flex or lex. Builds and runs +nicely under any ANSI/POSIX platform, including Linux and the free BSD +versions. Past versions of this code have run under DOS/Windows, +though whether it will still do so is unknown.

+ +Plans are afoot to supply distribution tarballs. + +

Other Tools

+ +

Jonathan Ferro has written an Intercal calculator mode for Emacs.

+ +

You can find out more about Kevin Stock's implementation of INTERCAL functions for PERL.

+ +

Alexander Garrett has written a Java class +implementing the INTERCAL math library.

+ +

An INTERCAL paper

+ +

Alexander Garrett wrote a paper on +INTERCAL for his Spring 1997 Programming Languages: Theory and +Design class. Alexander writes:

+ +
The obvious choice was INTERCAL (I'm still +quite surprised that I'm the only one who picked it — most people +did Java??). Anyway, it was not favourably received...when [the +professor] handed it back, he said, "Ah. I see you're someone with +a sense of humour. Unfortunately for you, I'm not."
+ +

We have corrected two typos (misspellings of "Malvernite" and +"compiler") in this copy.

+ +

Resource Pages

+ +

The co-maintainer of INTERCAL, Alex Smith, has an alternate INTERCAL HOME page. + +

Brian Raiter, who edited the revised version of the INTERCAL +manual available in HTML above, maintains a good INTERCAL +page.

+ +

Jacob Mandelson also has an INTERCAL +Page.

+ +

(The code from all of these home pages has been folded into the +INTERCAL distribution.)

+ +

Other Resources

+ +

There is an alt.lang.intercal Usenet +newsgroup.

+ +

Here's a transcript of a 1992 article by +Charles Stross. (Yes, the same Charles Stross as the +incandescently talented SF author, but this was a decade before he hit +the big time.)

+ +

In 2008, ComputerWorld inexplicably decided to +interview +Don Woods on INTERCAL. The results are both funny and informative.

+ +

Other Interesting Languages

+
    +
  • Befunge — +Computer Programming in multiple Directions, Dimensions, and +Topologies.
  • + +
  • BrainF*** +— An 8-instruction Turing-complete computer language.
  • + +
  • +Malebolge — Programming from Hell.
  • + +
  • +Unlambda — functional programming taken to a horrifying +extreme.
  • +
+ +

Related Links

+ +

If INTERCAL interests you, you may want to check out the Jargon File and the Retrocomputing Museum. Both +these pages and this one are maintained by Eric S. Raymond, who also +maintains a large collection of open-source software you may find +stimulating.

+ +
+ + + + diff --git a/website/iperl.html b/website/iperl.html new file mode 100644 index 0000000..ebbdd7c --- /dev/null +++ b/website/iperl.html @@ -0,0 +1,103 @@ + + + + + +iperl - INTERCAL in Perl + + + + + + + + + +
Back to Eric's Home PageUp to Site Map$Date: 2002-07-30 23:24:24 $
+
+

Using INTERCAL in Perl

+ +

Kevin Stock posted +the following to comp.sources.misc (Feb 1991):

+ +
+

I guess I must be cracking up. I've been trying to learn how to +use the usersubs stuff in Perl, and also how to program in +INTERCAL. Anyway, I ended up combining the two!

+ +

The following shar file is an instant mix package (just add +Perl) for Iperl, which is Perl plus the INTERCAL operators. There's +even a manual page - what more could you want?

+
+ +

Here is the contents of the README (from the archive):

+ +
+

I think this belongs somewhere alongside such films as "Abbot +and Costello meet Frankenstein's Monster". But, here it is anyway +...

+ +

PERL MEETS INTERCAL.

+ +

In this archive, you will find the usersubs stuff to add +INTERCAL functions to Perl. Unshar it somewhere (/dev/null would +probably do), and run make. (You may need to alter SRC in the +Makefile).

+ +

The resulting binary, iperl, will work just like perl with the +addition of the following INTERCAL functions:

+ +
    +
  • and16
  • + +
  • or16
  • + +
  • xor16
  • + +
  • and32
  • + +
  • or32
  • + +
  • xor32
  • + +
  • mingle
  • + +
  • select
  • +
+ +

The test file, op.ical, will run tests to ensure that the +functions work. This may be done using "make test".

+ +

The program iperlsh just reads in perl expressions (one per +line) and evaluates them.

+
+ +

Download iperl.tar.gz.

+ +

Or, here is the +Or, original shar from the usenet archives.

+ +

Return to the INTERCAL Resources +Page.

+ +
+ + + + + +
Back to Eric's Home PageUp to Site Map$Date: 2002-07-30 23:24:24 $
+ +
+
Eric S. Raymond <esr@snark.thyrsus.com>
+ + + diff --git a/website/nelson.html b/website/nelson.html new file mode 100644 index 0000000..7059627 --- /dev/null +++ b/website/nelson.html @@ -0,0 +1,149 @@ + + + + + + + + +Ted Nelson comments.... + + + + + + + + + +
Back to Eric's Home PageUp to Site Map$Date: 2002-07-30 23:35:36 $
+
+

Ted Nelson Comments...

+ +
+From ted@xanadu.net  Wed Dec  2 11:50:17 1998
+Return-Path: 
+Received: from localhost (esr@localhost [127.0.0.1])
+	by snark.thyrsus.com (8.8.7/8.8.7) with ESMTP id LAA27208
+	for ; Wed, 2 Dec 1998 11:50:15 -0500
+Received: from imap.ccil.org
+	by localhost with IMAP (fetchmail-4.6.9)
+	for esr@localhost (multi-drop); Wed, 02 Dec 1998 16:50:15 +0000 (UTC)
+Received: from mail.sfc.keio.ac.jp (mail.sfc.keio.ac.jp [133.27.4.120])
+	by locke.ccil.org (8.8.5/8.8.5) with ESMTP id MAA28871
+	for ; Wed, 2 Dec 1998 12:13:54 -0500 (EST)
+Received: from servix.sfc.keio.ac.jp (servix [133.27.104.66])
+	by mail.sfc.keio.ac.jp (8.9.1a/3.6Wbeta7-SFC) with SMTP id BAA15833;
+	Thu, 3 Dec 1998 01:43:37 +0900 (JST)
+Message-Id: <3.0.3.32.19981203012655.01d68d20@mail.sfc.keio.ac.jp>
+X-Sender: ted@mail.sfc.keio.ac.jp
+X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32)
+Date: Thu, 03 Dec 1998 01:26:55 +0900
+To: "Eric S. Raymond" 
+From: Ted Nelson 
+Subject: COME FROM statement considered asymmetrical  (CFasym.d6
+Cc: ted@sfc.keio.ac.jp, marlene@xanadu.net, erik@xanadu.net, xanni@xanadu.net,
+        eharter@din.or.jp, markm@ricochet.net,
+        drexler@imm.org (K. Eric Drexler), john@iecc.com, margy@iecc.com,
+        jordan@iecc.com, Nat Kuhn ,
+        Carol Baroudi , sw@tiac.net,
+        Charles Harris , fen@comedia.com,
+        "John Pettitt" , scriven@aol.com, colias@ascii.co.jp,
+        DickHeiser@aol.com, braun@sfo.com, penrose@sfc.keio.ac.jp,
+        jpost@earthlink.net (Jonathan Vos Post), farber@cis.upenn.edu
+Mime-Version: 1.0
+Content-Type: text/plain; charset="us-ascii"
+Status: RO
+Content-Length: 2980
+Lines: 64
+
+Hi Eric--
+
+I consider it marvelous that you have enhanced the world's
+ most obscure computer language, Intercal, by adding
+ Peter Ingerman's COME FROM statement.
+
+However, I should point out that COME FROM is not
+ a precise inverse of the GO TO statement.  True,
+ they are similar when each is one-to-one,
+ i.e. when each GOTO target/sink is pointed to by
+ only one GO TO, and each COME FROM receiver
+ is the unique recipient of its antecedent donor routine. 
+
+But the many-to-one case is asymmetrical: a number of
+ different GOTOs can have the same target, but a
+ COME FROM statement can only have a unique source.
+ And conversely: in the case of the GO TO, it is the antecedent
+ routine which can have only one target but can share it
+ with others; while in the case of the COME FROM,
+ it is the successor routines which can only share a single source.  
+
+This *could* be considered to be a deeper symmetry:
+ the possible many-to-one relation of the GO TO could be seen
+ as remapping into the possible one-to-many use of the COME FROM.
+
+But the asymmetry is stronger than that, being temporal
+ (and in some sense causative-- but this discussion must
+ skirt theology, and we know that A Programmer exists)--:
+ GO TO may only be temporally one-to-one or many-to-one,
+ while COME FROM may only be temporally one-to-one
+ or one-to-many.  If we took sexual behavior as an analogy,
+ the possible many-to-one relation of the GO TO is like being
+ gang-banged, with a relatively small variety of possible outcomes
+ (progeny), while the COME FROM is more like a bee going
+ from... oh, never mind.
+
+I hope this brings some measure of analytic rigor to a hitherto,
+ and justifiably, unknown problem area, where such rigor may
+ hitherto have been, and still may perhaps be, unwelcome.
+
+Best regards, Ted
+Gee, maybe I should submit this to Communications of the ACM...
+
+
+____________________________________________________
+Theodor Holm Nelson, Visiting Professor of Environmental Information
+ Keio University, Shonan Fujisawa Campus, Fujisawa, Japan
+ Home Fax from USA: 011-81-466-46-7368  (If in Japan, 0466-46-7368)
+http://www.sfc.keio.ac.jp/~ted/  (Professorial page)
+_____________________________________________________
+Permanent: Project Xanadu, 3020 Bridgeway #295, Sausalito CA 94965
+ Tel. 415/ 331-4422, fax 415/332-0136  
+http://www.xanadu.net (see also Professorial page, above)
+PERMANENT E-MAIL: ted@xanadu.net
+_____________________________________________________
+Quotation of the day, 98.12.02:
+Mike McNally, president of the Air Traffic Controllers Union, yesterday
+assured the press that air traffic controllers can take over from computers
+in case Y2K bugs hit the system.  
+     "I'm not trying to indicate that when our computers shut down that
+everything is hunky-dory.  There is a major transition period where the
+heart is beating and things are happening fast, and people are yelling and
+screaming to try to get a handle on it," he said.  (cnn.com, dateline
+98.12.01)
+
+
+ + +
+ + + + + + +
Back to Eric's Home PageUp to Site Map$Date: 2002-07-30 23:35:36 $
+ +
+
Eric S. Raymond <esr@thyrsus.com>
+ + + diff --git a/website/notfunny.png b/website/notfunny.png new file mode 100644 index 0000000..f17db9a Binary files /dev/null and b/website/notfunny.png differ diff --git a/website/paper.html b/website/paper.html new file mode 100644 index 0000000..aeaba9b --- /dev/null +++ b/website/paper.html @@ -0,0 +1,284 @@ + + + + +Abstraction and Modularity in INTERCAL + + + +
+
+
+
+

Not Funny! +Abstraction and Modularity in INTERCAL
+D. Alexander Garrett
+CS-538: Theory and Design of Programming Languages.
+

+ +

"And remember, when you look into the pit, the pit looks +back into you."
+         -- Anonymous +INTERCAL hacker

+ +

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[1]. 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.

+ +

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[2].

+ +

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:

+ +
DO:1<-#0$#256
+ +

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[3]. 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.

+ +

In addition to information hiding, multinational support is +also an important part of abstraction. As information exchange +causes the globe to shrink,[4] 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."[5] 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.

+ +

Until the new INTERCAL compiler with better RYM[6] 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[7]. 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.

+ +

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[8] (?). 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.[9]

+ +

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 +retro me iad[10]. 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:

+ +
(1) PLEASE <YOUR STATEMENT HERE>
+
+ +
.
+ .
+ .
+ +(2) DO COME FROM (1)
+ +

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.

+ +

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.[11] 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[12]. 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.[13]

+ +

INTERCAL is not even vaguely modular and nothing I can say +would persuade you that it was.

+ +

INTERCAL is a very dynamic, constantly evolving[14] 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.[15]

+ +

References
+

+ +
THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE +MANUAL, Woods, Donald R. and Lyon, James M. Revised by Howell, +Louis and Raymond, Eric S.
+ My pineal gland.
+ +

Afterword
+

+ +
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.
+ +
+
+
+
+[1] which +stands for "Compiler Language With No Pronouncable Acronym", +obviously.
+[2] There's a small sect of +Billyites who, pointing to Microsoft, claim that this has already +happened.
+[3]These examples shamelessly +cribbed from THE INTERCAL PROGRAMMING LANGUAGE REVISED REFERENCE +MANUAL, page 2.
+[4]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.
+[5]It might also look different, +depending on the font your terminal uses.
+[6]Read Your Mind
+[7]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.
+[8]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).
+[9]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".
+[10]"get thee behind me, GOTO," +obviously
+[11]Somebody's law of programming +seen on fortune: "Constants aren't; Variables don't."
+[12]The surest way to get a +SNUBbed variable to listen to you, again, is to offer it hot dogs +without any buns. Hail Eris!
+[13]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.
+[14]"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.
+[15]Confused? Good. Information +hiding.
+
+ +
+
+
+ + + diff --git a/website/stross.html b/website/stross.html new file mode 100644 index 0000000..3c6285f --- /dev/null +++ b/website/stross.html @@ -0,0 +1,336 @@ + + + + + + + + +INTERCAL -- the Language From Hell + + + + + + + + + +
Back to Intercal ResourcesUp to Site Map$Date: 2009-03-23 01:53:03 $
+ +
+The following article appeared in Computer Shopper (the British +magazine of that name, not the Ziff-Davis title) around September +1992. + +

Intercal -- the Language From Hell

+ +

Where would we be without effective programming +languages?

+ +

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?

+ +

Go back to slide rules, maybe.

+ +

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.

+ +

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.

+ +

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.

+ +

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 +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?

+ +

A load of old cobol'ers

+ +

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.

+ +

An icky mess

+ +

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:

+ +

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).

+ +

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).

+ +

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:

+ +

PLEASE DO IGNORE .1 +<-".1^C'&:51~"#V1^C!12~;&75SUB"V'V.1~

+ +

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.

+ +

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.

+ +

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

+ +

PLEASE ABSTAIN FROM IGNORING + FORGETTING

+ +

or

+ +

DO ABSTAIN FROM ABSTAINING

+ +

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.)

+ +

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 +(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.

+ +

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 +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.

+ +

Why you should program in Intercal

+ +

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.

+ +

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.

+ +

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

+ +

DO :1 <- #0$#256

+ +

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.)

+ +

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.

+ +

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 ...

+ +
+ + + + + + +
Back to Intercal ResourcesUp to Site Map$Date: 2009-03-23 01:53:03 $
+ +
+
Eric S. Raymond <esr@snark.thyrsus.com>
+ + +