From: Eric S. Raymond Date: Sat, 26 Feb 2000 06:15:57 +0000 (-0500) Subject: Remove a bug that wasn't, really. X-Git-Tag: 0.21~23 X-Git-Url: http://thyrsus.com/gitweb/?a=commitdiff_plain;h=16094ad5368217c5705d4ad8baa565b540062edb;p=intercal.git Remove a bug that wasn't, really. --- diff --git a/src/BUGS b/src/BUGS index bc3f194..8a5621c 100644 --- 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