[ghc-steering-committee] Deprecating Exports (#134); Recommendation: accept

Iavor Diatchki iavor.diatchki at gmail.com
Thu May 24 17:47:57 UTC 2018


Aha, yes, I see that `GlobalRdrElement` has a list of imports that caused
it to come in scope.  I guess then the main change in types would be to
`IfaceExport`, which is currently just an `AvailInfo` to something that
would keep track of what's deprecated.  Seems doable.

On Thu, May 24, 2018 at 10:35 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> in fact, GHC knows how something is imported; it uses this information to
> report redundant imports. So I can optimistically hope that the
> implementation effort is reasonable.
>
> Cheers,
> Joachim
>
>
> Am 24. Mai 2018 19:04:45 MESZ schrieb Iavor Diatchki <
> iavor.diatchki at gmail.com>:
> >I have a bunch of question about this proposal, but I wrote them on the
> >proposal discussion page, as this is what folks asked for, last time I
> >had
> >some questions.   I think answering them would make the proposal more
> >clear.
> >
> >It seems to me that the use of this extension is somewhat limited, but
> >it
> >could be useful on occasion so I could take it or leave it.    It's
> >been a
> >while since I've looked at the GHC source, but I don't think that
> >implementing this would be completely trivial, as I don't thing GHC
> >currently cares about *how* names came to in scope, just what they
> >refer
> >to.   But, I believe this is usually not a big factor in our
> >discussions,
> >just though I'd mention it.
> >
> >-Iavor
> >
> >
> >
> >
> >On Thu, May 24, 2018 at 3:23 AM Joachim Breitner
> ><mail at joachim-breitner.de>
> >wrote:
> >
> >> Hi,
> >>
> >> alanasp has proposed a Deprecating Exports mechanism:
> >>
> >>
> >
> https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst
> >>
> >> The gist is explained by this:
> >>
> >>    module Data.List
> >>    (  ...
> >>        {-# DEPRECATE lines "Exported from Data.String instead" #-}
> >>        , lines
> >>        ...t
> >>    ) where
> >>
> >> i.e. DEPRECATE pragmas in export lists cause warning when some other
> >> module uses the deprecated symbol when it is imported (only) via some
> >> deprecated export.
> >>
> >> This is a GSOC 2018 project, mentored by Matthew Pickering and Erik
> >de
> >> Castro Lopo.
> >>
> >> The feature has a clear use-case, is self-contained and David Feuer
> >> (the containers maintainer) has already confirmed that there is a
> >real
> >> demand for this. I suggest acceptance!
> >>
> >>
> >> As always, I will understand silence as tactic consensus.
> >>
> >> Cheers,
> >> Joachim
> >>
> >>
> >> --
> >> Joachim Breitner
> >>   mail at joachim-breitner.de
> >>   http://www.joachim-breitner.de/
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> >https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180524/b7b95e54/attachment.html>


More information about the ghc-steering-committee mailing list