Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!decwrl!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclskh!skh
From: skh@hpclskh.HP.COM
Newsgroups: comp.lang.misc
Subject: Re: error handling (was Re: Algol-style semicolons)
Message-ID: <960015@hpclskh.HP.COM>
Date: 19 Dec 88 19:48:42 GMT
References: <584@dms.UUCP>
Organization: Hewlett-Packard Calif. Language Lab
Lines: 32

>	Actually my nominee is the VAX-11C (vms) compiler which "corrects"
>
>	if ((( ... expression )) { ....
>to
>	if ((( ... expression ))) ...
>
>	That is, rather than inserting the required paren to balance the
>expression, it _replaces_ the '{' with a ')'. Needless to say, the
>corresponding brace imbalance leads to a torrent of further errors.
>I'm not a compiler writer (But I've played one on occasion :-)), but
>I thought that insertion was typically tried before substitution in
>this sort of case. Can any of you compiler gurus explain why this
>particular choice was made. Oh, yeah, we reported it but no reply and
>it's still there 3 versions later...
>
>Mike Albaugh (albaugh@dms.UUCP || {...decwrl!turtlevax!}weitek!dms!albaugh)

Yes, most correction schemes do try insertion before replacement.  And
in examples from earlier postings (not shown), many correction schemes refuse
to delete a symbol (thus leading to the frustrating ";" before "ELSE" problem).
At one time, deletion was considered in very bad taste, since the token was 
obviously provided by a programmer.  Newer correction schemes are much better.

However, I have found few production compilers which implement the newest
error correction schemes.  And replacing the error correction routines in a
WORKING compiler seems to be rare (probably thought to be not worth the
maintenance cost).  Working in the compiler field myself, I find this a sad
fact, but I can see the reasons.  Real compiler bugs always take precedence
over mediocre (or even poor) error correction.

skh
skh%hpclskh@hplabs.hp.com