Bikeshedding request for GHCi's :type

Eric Seidel eric at seidel.io
Wed Apr 27 00:18:02 UTC 2016


I think design A (deeply instantiate + generalize) produces the most
sensible types. I don't know what the curly braces mean (perhaps that we
can't use type application anymore since the order changed?) but I don't
think they'd show up at all without -fprint-explicit-foralls, right? If
so, I'm not too concerned about it.

I also think 2C is a neat idea and should be explored further, but I
don't think it should be the default behavior of :type. I've always
expected :type to print the exact type we would infer for the
expression.

Perhaps instead of changing the default behavior of :type or adding new
commands, we could add a flag to enhance :type's output. For example,

  > :type mapM
  mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
  > :set -fprint-type-specializations
  > :type mapM
  mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
  Possible Specializations:
  mapM :: Monad m => (a -> m b) -> [a] -> m [b]
  mapM :: (a -> Maybe b) -> [a] -> Maybe [b]
  ...

I think this could be useful even for experienced Haskellers, though I'm
a bit concerned that printing the full type at the top will leave
beginners as bewildered as ever..

Eric

On Tue, Apr 26, 2016, at 06:08, Richard Eisenberg wrote:
> Hi devs,
> 
> Over the weekend, I was pondering the Haskell course I will be teaching
> next year and shuddered at having to teach Foldable at the same time as
> `length`. So I implemented feature request #10963
> (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way
> for a user to request a specialization of a type. It all works
> wonderfully, but there is a real user-facing design issue here around the
> default behavior of :type and whether or not to add new :type-y like
> commands. I have outlined the situation here:
> https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> 
> I'd love some broad input on this issue. If you've got a stake in how
> this all works, please skim that wiki page and comment on #10963.
> 
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


More information about the ghc-devs mailing list