I have collected feedback gleaned here, on the ticket, and on reddit and summarized here: https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type#Summaryoffeedbackaboutthisissue
That summary includes this concrete proposal: 1. Ask for concrete suggestions about names for the new commands. 2. Use these names on my current implementation (which prints out only one specialization) 3. Post a feature request looking for more specializations. I simply don't have time to specify a design or implement an algorithm for printing out multiple specializations. Furthermore, my current implementation meets all specifications proffered for printing out multiple specializations, for all values of "multiple" that equal 1. It is easy to extend later. Separately, there is a groundswell of support for :doc, but that's beyond the scope of my work on this point. (I personally would love :doc, too.) So, what shall we name the two new commands? 1. A new command that specializes a type. (Currently with one specialization, but perhaps more examples in the future.) 2. A new command that preserves specialized type variables so that users of TypeApplications know what type parameters to pass in next. I have suggested :type-def for (1) and :type-spec for (2). I don't strongly like either. :examples and :inst have been suggested for (1). Any other ideas? Thanks! Richard On Apr 26, 2016, at 9:08 AM, Richard Eisenberg <e...@cis.upenn.edu> 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@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
