#10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm afraid I strongly disagree with the proposal in comment:5. * As we've discovered when looking at #11376 (specifically, see comment:31:ticket:11376), `:info` does not always give the type of a term (e.g. for data constructors, class methods, record selectors, pattern synonyms, and maybe more). It is not a good replacement for `:type`. * If we always default with `:type`, then, e.g., `:type foldr (:)` will report `[a] -> [a] -> [a]`. But it's actually much more useful than that, working over any `Foldable`. There would be no way to see that `foldr (:)` specializes the result container to be a list while not constraining the input container. * `:type-spec` is the answer to the issues in #11376. It's a generalization of comment:34:ticket:11376. You might argue that we shouldn't generalize here; your proposal on that ticket was to do `:type- spec` whenever the user asks for `:type` of a bare identifier. While I can't argue strongly against that proposal, I find the behavior unintuitive and frustratingly non-compositional. I do agree that three forms of `:type` is unfortunate. My original design was to have two forms, `:type` and `:type-info`, where `:type-info` printed out both the output of my current `:type-spec` and `:type-def`. (It actually originally printed out `:type` too, for good measure.) But I realized that a user rarely wants both of these outputs, so they should just be able to ask for what they want. It's very easy to go back to that other design, and I'm quite happy for new designs to be proposed. In particular, I don't think my current design is all that great. It's just better than Simon's, in my opinion. :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10963#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler