Mercurial > repo

comparison interps/c-intercal/BUGS @ 996:859f9b4339e6

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
<Gregor> tar xf egobot.tar.xz
author HackBot
date Sun, 09 Dec 2012 19:30:08 +0000
parents
children
comparison
equal deleted inserted replaced
995:6883f5911eb7 996:859f9b4339e6
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.