Proposal: Export String from Data.String (and two related proposals)

[Antoine Latter]

On Wed, Nov 17, 2010 at 4:06 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:
> On Wed, Nov 17, 2010 at 9:46 PM, Duncan Coutts
> <duncan.coutts at googlemail.com> wrote:
>>> 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.
>>
>> Yeah, I agree in principle, but probably best to leave that for later.
>
> It obviously needs to go through a deprecation phase.
>
> It would be great if we could {-# DEPRECATE #-} an export?
>
> So something like:
>
> module Data.List
>  (  ...
>  {-# DEPRECATE lines "Exported from Data.String instead" #-}
>  , lines
>  ...
>  ) where
> ...
> lines = ...
> ...
>
> Alternatively, we could just {-# DEPRECATE #-} the functions in
> Data.List and define equivalently named new ones in Data.String.
>

I thought about this, and I even thought it was a great idea, until I
realized that it would be a real bummer for anyone importing both
Data.List and Data.String - they would get an error from the compiler
unless they specifically hid the functions in question from one of the
imports.

There is a similar (but perhaps easier to solve?) problem with the
deprecated export - the compiler would need to not warn on use of the
function if it is imported from multiple sources and at least one of
the sources exports it non-deprecated.

Antoine