<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><span style="color:rgb(80,0,80)">>> Another non-descriptive style of error message that I admired was that</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> of Berkeley Pascal's syntax diagnostics. When the LR parser could not</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> proceed, it reported where, and automatically provided a sample token</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> that would allow the parsing to progress. I found this uniform</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> convention to be at least as informative as distinct hand-crafted</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> messages, which almost by definition can't foresee every contingency.</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">></span><span style="color:rgb(80,0,80)">> Alas, this elegant scheme seems not to have inspired imitators.</span><br></div><div dir="ltr"><span style="color:rgb(80,0,80)"><br></span></div><div dir="ltr"><span style="color:rgb(80,0,80)">> </span>The hazard with this approach is that the suggested syntactic correction</div><div dir="ltr">> might simply lead the user farther into the weeds<span style="color:rgb(80,0,80)"><br></span></div><div dir="ltr"><br></div><div>I don't think there's enough experience to justify this claim. Before I experienced the Berkeley compiler, I would have thought such bad outcomes were inevitable in any language. Although the compilers' suggestions often bore little or no relationship to the real correction,  I always found them informative. In particular, the utterly consistent style assured there was never an issue of ambiguity or of technical jargon.</div><div><br></div><div>The compiler taught me Pascal in an evening. I had scanned the Pascal Report a couple of years before but had never written a Pascal program. With no manual at hand, I looked at one program to find out what mumbo-jumbo had to come first and how to print integers, then wrote the rest by trial and error. Within a couple of hours  I had a working program good enough to pass muster in an ACM journal.</div><div><br></div><div>An example arose that one might think would lead "into the weeds". The parser balked before 'or' in a compound Boolean expression like  'a=b and c=d or x=y'. It couldn't suggest a right paren because no left paren had been seen. Whatever suggestion it did make (perhaps 'then') was enough to lead me to insert a remote left paren and teach me that parens are required around Boolean-valued subexpressions. (I will agree that this lesson might be less clear to a programming novice, but so might be many conventional diagnostics, e.g. "no effect".)</div><div><br></div><div>Doug</div><div><br></div></div></div></div></div></div></div></div></div></div></div></div>