[Haskell-cafe] Re: Extending the idea of a general Num to other types?

[ChrisK]

Dan Piponi wrote:
> On 9/5/07, Ketil Malde <ketil at ii.uib.no> wrote:
>> On Wed, 2007-09-05 at 08:19 +0100, Simon Peyton-Jones wrote:
>> Error message from GHCi:
>>     test/error.hs:2:8:
>>         No instance for (Num String)
>>           arising from use of `+' at test/error.hs:2:8-17
>>         Possible fix: add an instance declaration for (Num String)
>>         In the expression: x + (show s)
>>         In the definition of `f': f x s = x + (show s)
>>
>>>         your suggestion for the error message you'd like to have seen.
> 
> ghc --newbie-errors error.hs
> 
> . . .
> . . .

Well, most errors I get are what I would list as #1, and I would swap the order
of your error and expand them to make this ideal error message with 4 fixes.
The result is verbose, but I hope it is a helpful verbosity:

Error message from GHCi:
    test/error.hs:2:8:
        You have tried to apply the operator "+" to "x" and "show s"
        "show s" is a String.
        I don't know how to apply "+" to a String.
        May I suggest:
        (1) The inferred type "String" is not what you intended, fix the
operand(s) of "+".  Adding type annotations may help locate the code to fix.
        (2) You didn't really mean to type "+", change "+" to the desired name.
        (3) "+" is a method of type class Num.  Add an import for a module which
defines an "instance String Num".
        (4) "+" is a method of type class Num.  Tell me how to apply
"+" to a String by making String a new instance of the class Num (instance Num
String).
        In the expression: x + (show s)
        In the definition of `f': f x s = x + (show s)

A newbie is unlikely to need the (4)rd suggestion unless they are working on
classes and instances in which case they are likely to be able to understand it.
   I took the other suggestion on this list to also say (instance String Num) to
make which instance is missing precise.

Everyone not working on classes and instances will probably need a fix suggested
by (1) or (2) or (3).

The first two fixes are typographical errors of some kind.  The (2)nd error is a
typographical error in the error triggering code (here "+") that they ought to
be able to spot when it is pointed out.

I encounter problems caused by (1) fairly often.  The user did something (either
a logical error or a typo or wrong variable or accidentally shadowed the desired
variable, etc) that caused the type inference to find a type which does not (and
should not) have an instance of Num.  This can be an error anywhere in the
lexical scope of the error triggering code.  Adding type annotations as
assertions helps me move the error closer to the source of the problem, so I
added this suggestion.

The (3)rd error also trips me up.  But it is quickly remedied.

-- 
Chris