#4422: Export String from Data.String
---------------------------------+------------------------------------------
Reporter: basvandijk | Owner:
Type: proposal | Status: new
Priority: normal | Component: libraries/base
Version: 6.12.3 | Keywords:
Testcase: | Blockedby:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
== Proposals ==
This ticket makes three proposals, in order of importance IMHO:
1. 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.
2. 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.
3. 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 `String`s 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 `String`s 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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4422>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
