Remove a bug that wasn't, really.

diff --git a/src/BUGS b/src/BUGS
index bc3f1943688dc0bbfcd834aab3c711a614890ee4..8a5621c4a51c4ae8b6616750488f0187527efa3a 100644 (file)
--- a/src/BUGS
+++ b/src/BUGS
@@ -11,33 +11,7 @@ BLR = Brian Raiter
 
 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
@@ -55,7 +29,7 @@ BLR = Brian Raiter
    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.
@@ -66,7 +40,7 @@ BLR = Brian Raiter
    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