24 May
2012
24 May
'12
11:05 a.m.
On Wed, 23 May 2012, Stefan Skoglund wrote:
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for differences
between one build of the compiler and the result of the same build
iteration build of itself.
While it is an essential (arguable about whether truly NECESSARY) rite of
passage for the compiler's development, often there are BETTER test suites
for a compiler. The test suites should include large bodies of the kind
of code that the compiler is intended to process. For example, a compiler
for handling scientific calculations should be tested with a lot of those,
which is NOT what compiling the compiler will test.
If a compiler is being created for use in teaching beginners a language,
then perhaps the most important aspect of it would be the code-error
handling and reporting, whereas compiling the compiler is going to have
little or none of that. By the time the compiler is compiling itself,
there will presumably not be errors, and how many instances
(non-deliberate) will there be of
if(a=b)
if(...);
that the compiler should produce WARNINGs (not ERRORs) for?
Should the compiler suppress the warnings on the common case of
while(*t++=*s++); ?
Veering off onto that tangent (Compilers for Language Teaching), . . .
I would have loved to have had a C compiler explicitly for
TEACHING C that would have included a warning of
"WARNING: While valid C code, your prof will FLUNK YOU,
and you will get fired from jobs, if you don't improve
readability with some indenting!"
and
"WARNING: while valid C code, your total lack of comments will likely
be unacceptable to whomever you are writing this program for!"
"WARNING: while possibly valid, you have used a constant without
esplanation of its origin. Consider adding a comment to explain
what it is and where it came from."
"WARNING: when plagiarizing somebody else's project,
change more than just the variable names."
(OK, THAT is still a manual correction and message)
YES, teaching how to program in C (or any other language) is NOT
just about the technical requirements of the language itself.
YES, when teaching C (and other languages), I DID have requirements
besides that the program compile, run, and produce the correct output.
The GOALS are different when writing a program to perform a
specific task V writing a program to demonstrate proficiency.