|[10 earlier articles]|
|Re: Language used to write compilers firstname.lastname@example.org (2004-12-31)|
|Re: Language used to write compilers email@example.com (Ira Baxter) (2004-12-31)|
|Re: Language used to write compilers Peter_Flass@Yahoo.com (Peter Flass) (2005-01-01)|
|Re: Language used to write compilers firstname.lastname@example.org (2005-01-03)|
|Re: Language used to write compilers email@example.com (2005-01-03)|
|Re: Language used to write compilers firstname.lastname@example.org (2005-01-09)|
|Re: Language used to write compilers email@example.com (2005-01-12)|
|From:||firstname.lastname@example.org (Nick Maclaren)|
|Date:||12 Jan 2005 22:56:13 -0500|
|Organization:||University of Cambridge, England|
|Posted-Date:||12 Jan 2005 22:56:13 EST|
>>Slightly off-topic, but indicative, is the fact that almost no
>>compilers identify the line for both ends of a bracketting mismatch.
>Where would that make sense? An opening bracket too much is mismatched
>at EOF, and a closing bracket too much is mismatched at BOF?
>[There's more than one kind of bracket. If the parser sees a close
>paren when it's expecting a close brace, that's an error. Perl tells
>you where the open whatever was, and it's handy. -John]
Yes. If you have merely one type, then simple counting will do, but
with as few as two types, there are many other errors. It is more
than just handy in a large code - I have often had to descend to
binary chop to find where a problem is in C - and remember that it can
be in a macro, so it not easily visible :-(
Actually, there are cases even with a single type of brackets where
it can help. But I agree that it is a minor issue.
Return to the
Search the comp.compilers archives again.