Changes from CLC-INTERCAL 1.-94.-8 to 1.-94.-7

* New licence.

* Minor problems in the documentation fixed (could cause some fussy
  browsers to display the examples incorrectly).

Changes since CLC-INTERCAL 0.05

* NOTE: CONVERT and SWAP are currently unimplemented in the prerelease
  1.-94 compiler. Use the new CREATE and DESTROY instead (see below).

* ALSO NOTE: This file is sorted by decreasing order of sanity. You may
  stop reading at any point, but, if you continue, things are guaranteed
  to get worse.

* New version scheme including negative revision numbers has been introduced.

* "Version" renamed "perversion" for honesty.

* Implemented the just-too-late compiler people have heard me talking about:
  see file doc/just-too-late.pod

* Modified the operators to support Tri-INTERCAL (and all bases up to 7)
  and of course add the extra operators (Unary BUT, etc); the notation will
  be different from their C-INTERCAL's counterpart (because the whirlpool
  has already been used for classes); unary BUT is written ?; unary Add
  Without Carry is written | (in C-INTERCAL compatibility mode, BUT is @
  and Add is ^).

* Updated the WRITE IN code to allow input in Latin, like C-INTERCAL 0.20;
  also added an alternative spelling for Gaelic Neoni (0).

* Added new stashes. INTERCAL 1972 and C-INTERCAL have two stashes: one for
  the program counter (used by NEXT) and one for all the other registers.
  CLC-INTERCAL 0.05 had three (two independent ones for the program counter:
  did anybody notice that you can do NEXT from within a lecture, do a FINISH
  LECTURE, and you can still RESUME? In other words, you could do subroutine
  returns in the wrong order and it wold work (for INTERCAL values of work);
  after all, you can already stash registers and then retrieve them in the
  wrong order, as long as the registers are distinct).

  CLC-INTERCAL 1.-94 has sixteen independent stashes, but we aren't (yet)
  admitting what they are used for. It helps to remove that unfortunate
  resemblance between stashes and stacks. You can now stash a register
  several times and then retrieve it in any order, not just the reverse
  of the stashing. If this is confusing, don't worry, we can't figure out
  why one would want to do that either.

* Updated READ code to allow array slices (e.g. if ;1 is a 2-dimensional
  array, READ OUT ;1 SUB #2 will read out all elements of ;1 which have
  first subscript #2). For reasons which shall remain unexplained, WRITE IN
  can only use whole array or single elements, no slices (this, of course,
  might change in a future release).

* Implemented the CREATE statement, as well as its companion DESTROY: the
  syntax is different from what had been announced (but never implemented)
  before, and use of these statements require knowledge of the INTERCAL
  virtual machine, which will be documented in future (possibly). The parser
  is now provided in its source form (a list of CREATE statements), and this
  can be used as example by anybody who is interested to extend the compiler.
  A mini-compiler is provided in src/iacc.iacc (source) and src/iacc.io
  (object) to compile the full compiler.

* Implemented a new statement, the "NEXT FROM". This is similar to
  "COME FROM", except that the current position is stashed. For example,
  the two programs:

  (1) DO .1 <- #1              |     DO (2) NEXT
      PLEASE READ OUT .1       |     PLEASE READ OUT .1
      DO GIVE UP               |     DO GIVE UP
      DO NEXT FROM .1          | (2) DO .1 <- #2
      DO .1 <- #2              |     PLEASE RESUME #1
      PLEASE RESUME #1

  produce the same result ("II"). It is an error to have more than one
  "NEXT FROM" looking at the same label, or a "NEXT FROM" and a "COME FROM".
  This limitation might be removed in future releases. Also note that
  we think this new statement is cool, so you won't have to ask the compiler
  to include it (as you need to do with "NEXT"/"RESUME"/"FORGET"), it's
  always available.

* Also allowed "Gerund" forms of "COME FROM" and "NEXT FROM", so they now
  look like ABSTAINs and REINSTATEs in the grammar. There is an example
  in examples/quantum/come-from-gerund.gi; Since programs using this
  construct incur some performance penalty (every statement is now a potential
  target for a "COME FROM"/"NEXT FROM", not just ones with labels), it needs
  to be explicitly enabled by preloading "come-from-gerund" or using the
  suffix ".gi" instead of ".i"

* Also updated the definition of "GERUND" to include "COMMENTING" (which can
  be abbreviated "COMMENTS") - with all INTERCAL compilers, unrecognised
  statements are treated as comments; if they are executed, they print
  themselves as error messages and abort. Now it is possible to ignore
  errors by saying:

      PLEASE ABSTAIN FROM COMMENTING

  You can, of course, REINSTATE COMMENTS, although this might transform
  genuine comments ("PLEASE NOTE: THIS IS A COMMENT") into error messages.
  But then, you had a similar problem when comments had labels.

* Modified the initialisation code to make the command-line and the
  environment available to the program. These will be found in the special
  array registers ^1 and ^2, respectively. The arrays are bidimensional,
  with ^1 SUB #1 containing the first argument, ^1 SUB #2 the second, and
  so on. Needless to say, these arguments are provided as if they had been
  written in, so they are likely to be in Baudot or something as bad as that.
  A class library to implement associative arrays is going to be provided
  one day - this would be just what you need to use ^2 (the environment).

  Please note that these registers are used by the initialisation code, and
  are not normally accessible to the program (but see the next point)

* Made some of the program's internal state accessible to the program via a
  set of special registers (%n). For example, "DO %1 <- #1" will cause the
  program to do something unexpected (because %1 is the first part of the
  instruction pointer, the rest being %2 and %3). Note that a statement
  starting with "DO %1" can now be an assignment or something else, for
  example "DO %10 <- #1" is an assignment, and "DO %10 READ OUT .1" is a
  statement which reads out a register one time in ten. This is OK because
  IACC (the parser generator) happily accepts nondeterministic grammars, and
  sometimes even produces the expected results.

  The use of these registers should be limited to the compiler itself. In
  fact, they are currently only available to the compiler, but nobody stops
  the programmer from making them available with the appropriate CREATEs.

  If you really must, the list of these register is around line 82 of
  Language/INTERCAL/Object.pm -- look for %special_registers. Note that
  you cannot use any % or ^ register unless it's listed there, and you
  cannot always resize ^ registers. Some of the registers behave weirdly.

* Rewritten the write/read code to allow more flexibility from within the
  program - this is used by the compiler itself as well as by other things
  which are currently kept secret. The word "Outercal" has been uttered again.

* Added some more quantum constructs:

      DO register <- expression WHILE NOT ASSIGNING TO IT
      DO COME FROM (label) WHILE NOT COMING FROM THERE
      DO CREATE ... WHILE NOT CREATING IT
      DO DESTROY(... WHILE NOT DESTROYING IT
      DO ENROL register TO LEARN subjects WHILE NOT ENROLLING
      DO ENSLAVE register TO register WHILE LEAVING IT FREE
      DO FINISH LECTURE WHILE CONTINUING IT
      DO FORGET expression WHILE NOT FORGETTING
      DO FREE register TO register WHILE LEAVING IT IN SLAVERY
      DO NEXT FROM (label) WHILE NOT NEXTING FROM THERE
      DO GIVE UP WHILE CONTINUING TO RUN
      DO register GRADUATES WHILE REMAINING A STUDENT
      DO register LEARNS subject WHILE NOT LEARNING IT
      DO (label) NEXT WHILE NOT NEXTING
      DO RESUME expression WHILE NOT RESUMING
      DO RETRIEVE registers WHILE NOT RETRIEVING THEM
      DO STASH registers WHILE NOT STASHING THEM
      DO STUDY subject AT (label) IN CLASS @(number) WHILE NOT STUDYING IT
      DO WRITE IN registers WHILE NOT WRITING THEM

  Note that quantum assignment will also generate quantum bits on side effects:
  if the expression contains some overloading, the overloading will take effect
  while not taking effect; if the assignment modifies constants (see next
  point), they will retain their previous value while assuming a new one.
  This applies to most of the new constructs except (just to be different)
  quantum COME FROM, which always applies side effects but causes the program
  to jump while remaining stationary (similarly quantum NEXT FROM and
  behaves like quantum COME FROM)

  Examples for all forms of quantum constructs are found in directory
  examples/quantum: all these files can be compiled with the default
  CLC-INTERCAL compiler; in addition, examples/threads.i is a program
  which demonstrates the use of (non-quantum) threads, and must be
  compiled using the Threaded INTERCAL compatibility mode ("thick").

* Allowed to modify constants by assigning to an overloaded register, for
  example:

      PLEASE DO .1 <- .1/#1

  will (shock! horror!) leave the value of .1 unchanged, but at the same
  time modifies the value of #1 to whatever value was in .1 before the
  assignment. Note that this changes more than you might expect: for
  example, the "1" in ".1" will now change too... so when you try to
  assign to .1 (for example to restore #1 to its former value), you might
  get a different register. The way around it is:

      PLEASE DO .2 <- #1
      PLEASE ENSLAVE .2 TO .1
      DO .1 <- #1234
      DO .1 <- .1/#1
      DO SOMETHING WITH #1 CHANGED TO #1234
      DO $.2 <- .2
      DO FREE .2 FROM .1

  You need to use $.2, because .1 is not accessible in any other way. Of
  course, you are responsible for keeping the value of #2 constant during
  the above code.

  You probably guessed a simpler solution already:

      PLEASE DO .1234 <- #1
      PLEASE ENSLAVE .1234 TO .1
      DO .1 <- #1234
      DO .1 <- .1/#1
      DO SOMETHING WITH #1 CHANGED TO #1234
      DO $.1 <- .1
      DO FREE .1234 FROM .1

  This works because the references to .1 are really references to .1234,
  which of course contains .1; and $.1 is really $.1234 which is the real .1

  People who want to keep their sanity should avoid assigning to constants.
  (come to think of it, people who want to keep their sanity should avoid
  INTERCAL...)

  People who are not so worried about their sanity can read all about
  overloading in the documentation.

* A new operating system interface is available via the use of the special
  register %OS and the compiler module "syscall.iacc" (which can be added to
  sick by using the option "-psick -psyscall" or, better, "--suffix=si").
  After you added "syscall.iacc" to your program, it will behave as if the
  operating system had, lurking in its darkest corner, the statement:

      DO NEXT FROM (666)

  (In fact, it is a computed NEXT FROM and the label is specified by the
  internal register %OS; however, since the register is not accessible to
  the program, it is just as good as a noncomputed one, unless you use CREATE
  to make the register accessible). The operation code is contained in
  register +.1-$%OS which is just a shortand for "the spot register with the
  same number as the last register assigned to before the system call". For
  example, the following:

      (666) DO .666 <- #2

  would execute system operation #2, whatever it is. However, the following:

      (666) DO :123 <- #2

  would execute the system operation with code in .123 (the assignment was to
  :123, which of course does not alter .123, but sets the register number to
  be used to 123, so the expression "+.1-$%OS" becomes equivalent to
  "+.1-:123" which is of course ".123".

  Also note that if a thread has never assigned to a register, it is an error
  to use the syscall interface. A program starting with:

      (666) DO NOT GIVE UP

  would therefore produce an error.

  One more note, "writing" a register means assigning to it. For example,
  the following program would obtain a system operation number from the
  operator:

      (666) PLEASE WRITE IN .1

  An then there is:

      (666) DO RETRIEVE :1 + ,2 + ;3

  which can decide to use .1, .2 or .3 depending on the actual order of
  evaluation (the RETRIEVE is considered to modify all the registers listed).
  In all versions of CLC-INTERCAL, registers are retrieved in order, so,
  until we change something, this uses .3 for the opcode.

  Enslaving, freeing, enrolling and graduating are not considered
  modifications in this context. Overloading is also not considered a
  modification (including assignment to overloads) although it probably
  ought to be. If you want consistency, don't use INTERCAL. For example:

            PLEASE .1 <- .2/#3
      (666) DO .2 <- #4

  would execute the system call with ".1", not ".2", because the last
  assignment is to an overloaded register (in fact, it is altering #3
  to be the same as #4, so it is not assigning to a register at all!)

  The list of system operations does not necessarily correspond with the
  O.S. kernel's list of syscalls, or with anything else. It is currently
  documented only by the self-explanatory source code in syscall.i - which
  also doubles as example for "COME FROM GERUND" and "CREATE".

  Parameters to the call are contained in registers with the same number
  as the opcode: +:1-$%OS for numbers, +,1-$%OS for strings and +;1-$%OS
  for lists of numbers. Of course, some opcodes have nonstandard calling
  conventions.

  It is possible to disable system calls using "DO ABSTAIN FROM NEXTING FROM",
  and re-enable them with "DO REINSTATE NEXTING FROM".

* Since you are still here, you can read the comment before subroutine
  _forall_statement() in Language::INTERCAL::Object and reproduced below:

  # The following subroutine handles the rather dubious case in which the
  # compiled program has changed, and the program counter needs adjusting
  # in all threads to find where the current code has gone. The reason it
  # is called _forall_statements is because this can only happen when we
  # sweep through the program, for example to find come froms, labels, and
  # what have you. In all other cases, the program counter automagically
  # adapts to the code. Really. Look at _run_code() if you don't believe me

