Re: Languages that are hard to parse

glen herrmannsfeldt <gah@ugcs.caltech.edu>
22 May 2005 00:55:27 -0400

          From comp.compilers

Related articles
[2 earlier articles]
Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-18)
Re: Languages that are hard to parse gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-18)
Re: Languages that are hard to parse Peter_Flass@Yahoo.com (Peter Flass) (2005-05-19)
Re: Languages that are hard to parse gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-20)
Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-20)
Re: Languages that are hard to parse henry@spsystems.net (2005-05-21)
Re: Languages that are hard to parse gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-05-22)
Re: Languages that are hard to parse Satyam@satyam.com.ar (Satyam) (2005-05-22)
Re: Languages that are hard to parse DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-22)
Re: Languages that are hard to parse dot@dotat.at (Tony Finch) (2005-05-24)
Re: Languages that are hard to parse wclodius@lanl.gov (2005-05-24)
Re: Languages that are hard to parse Martin.Ward@durham.ac.uk (Martin Ward) (2005-05-24)
Re: Languages that are hard to parse ralph@inputplus.co.uk (2005-05-26)
[3 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 22 May 2005 00:55:27 -0400
Organization: Compilers Central
References: 05-05-119 05-05-155 05-05-166 05-05-182 05-05-192
Keywords: testing

Henry Spencer wrote:


(snip regarding COBOL programming)


> For example, on the first
> assignment, the prof told us that we would be graded on how our code
> performed on *his* test data, warned us that it was full of errors and
> inconsistencies, and said that we would be penalized heavily for every
> data problem that our code failed to detect and report. I can think of
> some compiler writers who should have taken that course...


I might have mentioned it before, but this reminds me again of stories
I used to hear about testing compilers with cards from the card
recycling bin. (It seems that cards were higher quality paper so it
was worthwhile to keep them separate.)


Presumably that selects for the kinds of errors that programmers might
make, not to mention the random order of the statements. Also, much
easier than trying to write lines of buggy code to confuse compilers
with. Now that cards are gone, it is hard to find a good substitute.


-- glen


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.