error message suggestions

Alan Grover awgrover@umich.edu
Mon, 9 Mar 1998 09:32:44 -0500


A number of suggestions for error messages:


The error messages from the compiler could be made clearer. For example:
	Type error [test.icl,20,bother]: "pList" no instance available of
type AETEInfo
should indicate the class which has no instance (presumeably it is
complaining that AETEInfo does not have an instance of toString defined):
	bother :: !*File *Files-> (!*File, !*Files)
	bother stdinout files		// error flagged for this line
		#!	stdinout = pList std makeAETEInfoList	// should
be flagged for this line
		= (stdinout, files)
			where
				pList :: *File [a] -> !*File | toString a;
				pList std theList = std <<< "" <<<
(list2String theList) <<< "\n"
The line indicated (20), is actually the first line of the "bother"
function. Many of the error messages flag errors at the first line of the
global function. It would be nice if they indicated the actual line.

Often I get the function/variable "blah-blah not used" message. Often I
should like to know why. Could I please ask the compiler to find out why?
As I become more proficient in Clean, I get quicker at guessing why, but
sometimes it's obscure or unexpected. Beginners would appreciate this, I
think.

A narrative would be a useful way of explaining:

Blah-blah is the return value of ZZZ,

which is in a "lets" construct,

which isn't a strict "lets",

but is not returned from the enclosing Fubor,

or

Blah-blah is the non-strict return value of ZZZ,

which is in a non-strict "lets" construct,

and is returned by the enclosing Fubor,

but isn't used by the calling Ognir. <WhyNot?>

or

Blah-blah isn't used in Ognir

although it does appear as the argument for Lub,

Lub doesn't take it as a strict argument,

and Lub doesn't use it <WhyNot?>

and Ognir doesn't return it (so noone else can use it),

and Blah-Blah isn't in any Strict context (like a strict "lets", or as a
strict parameter).

The "WhyNot" could expand into a further narrative about use of the value.

Note the importance of explaining both why it might otherwise be used (it
is returned), and why it is not in-fact used.

This narrative technique would be nice to have for other error/warning
messages that are caused by a-more-than-just-local context. A test for this
locality: is the reason for the message on one line?

---
"Alan Grover, Technical Pb" awgrover@umich.edu
+1 (743) 647-5778
Project Leader
Health Media Research Lab, Cancer Center
5D04 North Ingalls Building, Mail Stop 0471
300 North Ingalls
Ann Arbor, MI 48109-0471