From 16094ad5368217c5705d4ad8baa565b540062edb Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Sat, 26 Feb 2000 01:15:57 -0500 Subject: [PATCH] Remove a bug that wasn't, really. --- src/BUGS | 32 +++----------------------------- 1 file changed, 3 insertions(+), 29 deletions(-) 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 -- 2.43.0