Odd error message

[Tom Davies]

I'm getting this error message in ICE:

CAL: Compilation unsuccessful because of errors:
Error: TDavies.FastEndo: Type error applying the operator "!=" to
its first argument. Caused by: Type clash: type
TDavies.FastArray.FastArray Cal.Core.Prelude.Char is not a member of
type class Cal.Core.Prelude.Eq.
Error: TDavies.FastEndo: Ambiguous type signature in inferred type
Cal.Core.Prelude.Eq a => a.
Info: TDavies.FastEndo: Not able to recover from previous
compilation error(s).

Note that there is no line number in the message.

The only place in the module which uses '!=' explicitly is:

search :: FastArray Char -> Int -> Int -> FastArray Char -> Maybe Int;
search dna startat n sl =
let
c1 :: Char;
c1 = subscript dna (startat + n);
c2 :: Char;
c2 = subscript sl n;
in
if length sl == n then Just startat
else if c1 != c2 then Nothing else search dna startat (n+1) sl;

which looks perfectly safe.

What am I missing?

[Tom Davies]

It appears that the problem was trying to derive Eq for this type:

data PItem = Base base :: Char | Skip n :: !Int | Search dna ::
(FastArray Char) | OpenGroup | CloseGroup deriving Eq, Outputable;

When FastArray a didn't derive Eq -- fair enough, but a rather
confusing message.

Tom

[Bo Ilic]

Hi Tom,
Deriving clauses are implemented by (under the covers) generating the
required instance declarations. If for whatever reason this can't be
done, the error you get, as you point out, is quite confusing; it is a
type-error in a hidden function! This is a known problem, and the
eventual plan is to give a message explaining why the deriving clause
is not valid. However, in the shorter term, we're planning on marking
the hidden functions with the line-column position of the type class
within the deriving clause. This should hopefully make it easier to
figure out the problem.

Also, note that there is a generate command in ICE that generates the
code that would be generated by a deriving clause for all type classes
for that type (:gen deriving typeName). This is useful if you want to
have better error information (i.e. use the generate command, paste in
the code, comment out the deriving clause and recompile the module).
Another application is when one wants to manually edit the deriving
generated code to not use the exact semantics of the deriving clause,
but something related i.e. it saves typing.

Cheers,
Bo

[Tom Davies]

On Sep 5, 6:23 am, Bo Ilic <bo.i...@businessobjects.com> wrote:
> However, in the shorter term, we're planning on marking
> the hidden functions with the line-column position of the type class
> within the deriving clause.

That would have given me a clue faster -- not that it took too long,
and I guess its only confusing the first time...

Tom