19 May
2024
19 May
'24
4:21 p.m.
Ack! I finger-fumbled and accidentally sent this message incomplete.
Here's the complete version. Sorry about that, Chief!
On Sun, May 19, 2024 at 12:18 PM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
On Sun, May 19, 2024 at 10:03 AM Douglas McIlroy <
douglas.mcilroy(a)dartmouth.edu> wrote:
Commercial compiler writers avoid this technique because it turns into an
error report generator. The potential user benefit is outweighed by all of
the "your compiler suggested X as a correction when the problem was Y"
that need to be answered.
-Paul W.
Another non-descriptive style of error message that I admired was that of
Berkeley Pascal's syntax diagnostics. When the LR parser could not proceed,
it reported where, and automatically provided a sample token that would
allow the parsing to progress. I found this uniform convention to be at
least as informative as distinct hand-crafted messages, which almost by
definition can't foresee every contingency. Alas, this elegant scheme seems
not to have inspired imitators.
The hazard with this approach is that the suggested syntactic correction
might
simply lead the user farther into the weeds. It depends on how far
the parse has gone off the rails before a grammatical error is found.
Pascal and BASIC (at least the original Dartmouth BASIC) have simple,
well-behaved grammars and the suggested syntactic correction is likely to
be correct. It doesn't work as well for more syntactically complicated
languages such as C (consider an error resulting from use of == instead of
=) or PL/I. And it's nigh on impossible for languages with ill-behaved
grammars such as Fortran and COBOL (among other grammatical evils, Fortran
has context-sensitive lexiing).
Commercial compiler writers avoid this techniq