Changes between Version 1 and Version 3 of Ticket #1696


Ignore:
Timestamp:
Sep 18, 2007 8:10:34 AM (8 years ago)
Author:
simonpj
Comment:

Ah now I see. When you say

:t (^)

GHC infers the type of the (rather small) expression (^). In doing so, it instantiates the function and re-generalises it. That jumbles up the constraints.

Random thoughts:

  • We could have a special case for :t of a single identifier, which simply prints the type of the identifier. That would be a bit of a hack, but would eliminate any jumbling in a common case.
  • When GHCi displays a type for the user, it drops the foralls, and combines constraints (actually this is a recent fix). It could do more: it could re-order the constraints to look nicer.
  • Alternatively, when generalising, GHC could sort the constraints (and perhaps the type variables too) into a nicer order. That would entail extra work that would usually go unseen; but perhaps it'd be worth it.

I don't this this is very high priority, but I'm jotting down these notes so that we don't lose the thought. Thanks for raising it.

Simon

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1696

    • Property Priority changed from normal to low
    • Property Component changed from Compiler to Compiler (Type checker)
    • Property Milestone changed from to _|_
  • Ticket #1696 – Description

    v1 v3  
    1 I was working with some buggy numerical code of mine, and I was having problems with some types involving exponentiation. My working hypothesis was that the problem involved using ^ with a numerical type I had defined - I had checked ^'s type through :t and saw:
     1I was working with some buggy numerical code of mine, and I was having problems with some types involving exponentiation. My working hypothesis was that the problem involved using `(^)` with a numerical type I had defined - I had checked `(^)`'s type through :t and saw:
    22{{{
    33 (^) :: forall a b. (Integral b, Num a) => a -> b -> a