Lambda the Ultimate

VB6 sometimes produces the error "Undefined Type", displayed in a message box without providing any context whatsoever (no name for the offending type and no location, not even the name of the source file - it could be anywhere in the project).
As a response you get to click "Ok" and the compilation aborts.

Disclaimer: I don't use VB6 out of personal choice ...

Thanks, g++!

Notable: GHC's "Expression has type a, expected type a"

... would have been a better title.

Anywayz, here's my own small (ocaml) pearl:

This kind of expression is not allowed as right-hand side of `let rec'.

Fortunately, these days we can google for quick fixes.

Overheard from an overworked student in a C++ course:

Microsoft VC++: Ambigious Error
Student: Oh, I'm ambigious?!!

Way back in the old days, when I was in junior high school, I entertained myself by learning C with my trusty second-hand copy of Turbo C++ 1.0. I hadn't grasped yet that a switch statement could only switch on something of integer value, and so tried something of the following seemingly reasonable (at the time) form:

switch(someString)
{
case "someValue":
{
/* Do something */
break;
}

default:
{
/* Complain */
break;
}
}

Anyway, what I got out of the compiler was "Non-integral switch expression." Not being immediately able to decode the meaning of this error, I decided to look it up in the manual. Borland's crystal clear explanation of the matter: "The switch expression you have attempted to use is not integral."

My greatest moment of aggravation with a compiler was actually due to the absence of an error message.

The C++ standard says "no length limits on names". Borland C++ 3.0 said "the length limit is 255 characters", which was pretty reasonable. But, in fact, the Borland linker had an undocumented limit of 63 characters--and, of course, this was on the munged name. So it was relatively easy (especially if you were using long names and/or nested classes) to hit the 63-character limit.

Now, if the compiler had thrown up an error message when it hit this limit, that would have been OK--a minor irritation, but usually a pretty easy one to work around.

It didn't. It just truncated the munged name to 63 characters.

Now, that's bad enough; but, in practice, the first 63 characters were often unique, so it could have worked. The problem was that, when the compiler called a function with a truncated name, it didn't pass any parameters on the stack.

Mind you, there was no reciprocal bug in the code generation for the function with a truncated name; it was still trying to read the parameters off the stack. If one of these parameters (say, the implicit this) was a pointer, the function then went on to trash memory. Since this was on Windows 3.1, this almost always meant at least a reboot, sometimes a reinstall.

It took me quite a while to figure out what was going on; I wound up having to inspect the generated assembly code. I submitted a bug to Borland, but, oddly enough, I never heard back. ;-)

PL-6, the system programming language of the old Honeywell CP-6 Operating System had a most useful message that would occur from time to time:

"Error found between beginning and end of file."

Fortunately, once you found someone who knew what was wrong, it was fairly easy to fix. But the first time you saw this you weren't too pleased. You usually went chopping code out until you found the offending area and then deduced what was wrong. [BTW, it was an incorrectly called macro without a trailing semicolon, most times]

And, no, the manual was of no use. It just said that your code had errors.

{Show {fun {$ X X} foo end bar baz}}

The Oz Emulator says:

%**** Error: conditional failed *****************
%**
%** Missing else clause
%**
%** Matching: baz

As VB and ActiveX were already mentioned, and parsers in fact are pretty close in spirit to compilers' lexers...

org.xml.sax.SAXParseException: The processing instruction target matching "[xX][mM][lL]" is not allowed.

Cause unidentified, the problem disappeared without changing the input file.

CMUCL once gave me an error something like

Error: 42 is not a number.

This was due to a type-inferencing bug incorrectly deciding that a variable could never be bound to a number at a certain point and that a runtime type-error should be signalled without checking the value.

Ken Thompson is known for parsimonious error messages. (The ubiquitous "?" from ed is [in]famous.) He mentioned a (FORTRAN?) compiler once (mercifully never released) that produced only two syntax error messages: JIM and JOE, for "Junk In Middle" and "Junk Off End".

APL\360 occasionally produced "nonce error", which was its abstruse way of saying that what you typed was legal, but the implementation wasn't capable of handling it. If you've seen Duff's Device you might understand why I know this.