			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.
