[GHC] #10963: Beginner-targeted language extension
GHC
ghc-devs at haskell.org
Mon Apr 25 12:13:42 UTC 2016
#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
More information about the ghc-tickets
mailing list