Unfriend error message

[Bulat Ziganshin]

Hello Simon,

You are requested us to give you examples of bad messages about
program errors. This message is due to use of "all" instead of "and".
in this case it would be great to hear that "all" has type of "(a ->
Bool) -> [a] -> Bool" instead of needed "[Bool] -> Bool". May be in
this case GHC tries to be smarter than needed :-)

data PackedFilePath = PackedFilePath
  { fpPackedDirectory   :: !String
  , fpPackedBasename    :: !String
  , fpHash              ::  Int
  }

map2eq  f x y  =  (f x) == (f y)

instance Eq PackedFilePath where
  a==b  =  all [ map2eq fpHash            a b
               , map2eq fpPackedBasename  a b
               , map2eq fpPackedDirectory a b
               ]

c.hs:10:11:
    Couldn't match `Bool' against `t -> t1'
      Expected type: Bool
      Inferred type: t -> t1
      Expected type: Bool
      Inferred type: [a] -> Bool
    Probable cause: `all' is applied to too few arguments in the call
        (all [map2eq fpHash a b, map2eq fpPackedBasename a b,
              map2eq fpPackedDirectory a b])

The HUGS message again a little more informative:

ERROR "C:\temp\c.hs":10 - Type error in application
*** Expression     : all [map2eq fpHash a b,map2eq fpPackedBasename a b,map2eq fpPackedDirectory a b]
*** Term           : [map2eq fpHash a b,map2eq fpPackedBasename a b,map2eq fpPackedDirectory a b]
*** Type           : [Bool]
*** Does not match : a -> Bool


btw, i share the viewpoint that GHC messages are close to unusable.
The main information i extract from them is an exact error location.
may be (may be!) it is better to render error messages in terms of
terms ;) with KNOWN TYPES, such as "all" in this case. while the
Haskell officially is functional language and any term can be a
fixed function or some data, in real programs there is some base
things which have a fixed meaning and organize the whole computation
process. concentrating on such things (i.e. functions with known
types) instead of concentrating on types of isolated terms may approach
you to not-so-smart programmers using GHC like me :)  may be it is a
viewpoint of old imperative programmer which accustomed to having
two different beasts - procedures with well-known types and data which
can or cannot be processed by these procedures, but both GHC and HUGS
in this example says nothing about that cause of error message was
that "all" wants arguments of this concrete types


-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com