Ticket #4422 (closed proposal: fixed)
Export String from Data.String
| Reported by: | basvandijk | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Not GHC |
| Component: | libraries/base | Version: | 6.12.3 |
| Keywords: | Cc: | ||
| Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
| Type of failure: | None/Unknown | Difficulty: | |
| Test Case: | Blocked By: | ||
| Blocking: | Related Tickets: |
Description
Proposals
This ticket makes three proposals, in order of importance IMHO:
- Export String from Data.String. Most modules in base and on Hackage of the form: Data.<type> also export <type>. I think it's surprising and confusing that Data.String doesn't conform to this pattern.
- Unexport String from Data.Char. I feel less strongly about this one, but in general I think it is good that a symbol is exported from as few modules as possible.
- Export the String operations: lines, words, unlines and unwords from Data.String. I feel even less strongly about this one. However these are operations on Strings so it makes sense to export them from Data.String. As a counter argument you could say these operations either receive or produce a list of Strings so they only belong in Data.List.
If we accept 3 then in the spirit of export a symbol from as few modules as possible, you may expect a fourth proposal: Unexport the String operations: lines, words, unlines and unwords from Data.List. However I think this will break lots of programs. I have no problem also discussing this one though.
Attached is a patch bundle with three patches that implement the three proposals. We may end up deciding to apply only a few of them.
Discussion deadline
3 weeks from now: Wednesday 10 November.
Attachments
Change History
Note: See
TracTickets for help on using
tickets.

