Type synonyms in error messages

type Foo = {foo::Int}

bar :: Foo -> _
bar x = x + 1

Is it possible to use Foo instead of { foo :: Int} in error message?
It's much harder to understand the error especially with big records.

Could not match type

     { foo :: Int
     }

   with type

     Int


 while trying to match type { foo :: Int
                            }
   with type Int
 while checking that type { foo :: Int
                          }
   is at least as general as type Int
 while checking that type Int
   is at least as general as type { foo :: Int
                                  }
 while checking that expression 1
   has type { foo :: Int
            }
 while applying a function ((+) (#dict Semiring _1)) x
   of type _1 -> _1
   to argument 1
 while inferring the type of ((+) x) 1
 while checking that expression ((+) x) 1
   has type _0
 while checking that expression \x ->
                                  ((+) x) 1
   has type { foo :: Int
            }
            -> _0
 in value declaration bar

 where _0 is an unknown type
       _1 is an unknown type

While I don't agree that the provided example is easier with collapsed type synonyms (I would prefer to see { foo :: Int } in the error message), it would be nice if the compiler could collapse those expanded type names after a configurable amount of levels (e.g. first n levels would be shown expanded, and other would remain as they were in code). For instance in halogen type synonyms allow to manage components more-or-less conveniently. But when you start rearranging them error messages can span across multiple screens.

From the implementation point of view, if I understand correctly, type synonyms are fully expanded during compilation, so it's probably not that easy to restore the original names.

I think it's probably sensible for the compiler to say, "if there is a synonym in scope for this type, then that probably means the human finds the synonym easier to understand, so I should use the synonym". If the synonym were not easier to understand, presumably, it would have no reason to exist? At least, in most cases. My gut feeling is that this reasoning will apply in enough cases for it to be a sensible approach.

GHC does use type synonyms in its error messages, so while it may not be easy, it certainly ought to be possible, right?

The information is gone by the time it reaches these kind of errors. Synonyms are fully desugared as we kept running into cases where synonyms were incorrectly handled.

It definitely is possible to retain some use of synonyms for errors/warnings, it's something I intend to revisit in 0.9 perhaps.

See #1443 for the kind of problems synonyms can still cause, even despite the earlier desugaring pass we have now 😉

@garyb

We used to keep synonyms around through type checking, but as @garyb noted, it led to some issues. It could be done better though.

@garyb

I think this is another issue which will be simplified by the annotations work @garyb is doing, since we can annotate the expanded type during synonym expansion, and then look for it during pretty printing.

Navigation Menu

Repository navigation

Type synonyms in error messages #1821

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Type synonyms in error messages #1821

Description

Activity

zudov commented on Jan 19, 2016

hdgarrood commented on Jan 19, 2016

garyb commented on Jan 19, 2016

garyb commented on Jan 19, 2016

paf31 commented on Jan 19, 2016

paf31 commented on Apr 15, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions