|
996
|
1 BUGS
|
|
|
2
|
|
|
3 There are still some known bugs in INTERCAL (and no doubt many we don't even
|
|
|
4 suspect as yet). The following list accumulates current bug reports and
|
|
|
5 TO DO agenda items through the current release.
|
|
|
6
|
|
|
7 ESR = Eric S. Raymond
|
|
|
8 SS = Steve Swales
|
|
|
9 LHH = Louis Howell
|
|
|
10 BLR = Brian Raiter
|
|
|
11 AIS = Alex Smith
|
|
|
12
|
|
|
13 1) (ESR) INTERCAL would be intrinsically a crock even if it worked right.
|
|
|
14
|
|
|
15 2) (BLR) I have hacked up a fix to the problem with line numbers being off
|
|
|
16 due to statements sharing/spanning lines. The parser now stores the
|
|
|
17 starting line number for all tuples, not just the splatted
|
|
|
18 ones. Not only does this give synchronized lines in the comments in
|
|
|
19 the degenerated C code, but run-time error messages are just as
|
|
|
20 reliable as the parse/compile-time ones. The line number in the
|
|
|
21 error message is actually the line number of the next statement
|
|
|
22 (e.g., if the next statement is on the same line, the line number
|
|
|
23 of both statements will be used).
|
|
|
24
|
|
|
25 Note that I said "just as reliable," as opposed to "fully
|
|
|
26 reliable". Since the lexer doesn't know where the line ends until
|
|
|
27 after it's already parsed the preamble (DO-PLEASE combo, line
|
|
|
28 label, oh-oh-seven number, etc) of the following line, it actually
|
|
|
29 stores as the starting line number the first non-whitespace of the
|
|
|
30 statement proper. So if a statement has its preamble on one line
|
|
|
31 and the rest of it on the next, the preamble will be beheaded.
|
|
|
32
|
|
|
33 Still, it's a vast improvement, and as LHH pointed out, it's not
|
|
|
34 going to get much better without writing a preprocessing lexer that
|
|
|
35 can actually separate out the statements before any real parsing
|
|
|
36 begins. Until someone wants to do that, this will do nicely, I think.
|
|
|
37
|
|
|
38 As a side bonus, splatting now shows the entire statement. (Er,
|
|
|
39 except when the statement both spans and shares a line. If a multi-
|
|
|
40 line statement ends on the same line as the beginning of the next
|
|
|
41 statement, the last part will get truncated. Again, not a case we
|
|
|
42 want to be encouraging people to explore anyway.)
|
|
|
43
|
|
|
44 3) (BLR) Interleave does not check the type of its arguments. The manual
|
|
|
45 insinuates that interleaving 32-bit values should result in error 533;
|
|
|
46 instead, C-INTERCAL silently truncates them to 16 bits. Unfortunately,
|
|
|
47 the modified behavior of select's return type depends on this, so
|
|
|
48 there's not much we can do about it as things stand.
|
|
|
49
|
|
|
50 4) (AIS) Reverse assignments (those with the expression on the left)
|
|
|
51 are very unlikely to work in bases other than 2. (The current code
|
|
|
52 calculates what the answer would be in base 2 and throws an error
|
|
|
53 if it isn't correct for the current base.)
|
|
|
54
|
|
|
55 5) (AIS) Some of the newer features in intercal.el are not yet fully
|
|
|
56 implemented and have a tendency to print 'Unimplemented' rather
|
|
|
57 than doing anything useful.
|
|
|
58
|
|
|
59 6) (AIS) The external call system only works with gcc (due to its need
|
|
|
60 to pass command-line arguments like -x and -E to it), and fails
|
|
|
61 when mixed with come-from-gerund and next-from-gerund.
|
|
|
62
|
|
|
63 TO DO
|
|
|
64
|
|
|
65 1. (ESR) Add more optimization templates, esp. idioms for +, -, *, /.
|
|
|
66
|
|
|
67 2. (ESR) Forget this @!%$#! crock and take a long vacation.
|
