We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet.

Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy.

Janek

On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek

wrote:

...

I want to deprecate some Template Haskell functions in GHC 7.12 and then remove them in GHC 7.14 (or whatever version that comes after 7.12). Do we have any workflow for remembering these kind of things? I was thinking about adding a conditional error:

#if __GLASGOW_HASKELL__ > 712 #error Remove functions foo bar from TH #endif

Is this a good way of doing this? Or should I do it differently?

Janek _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka wrote:

On 09/01/15 12:02, Jan Stolarek wrote:

...

...

We could file a tracking bug against the 7.14 milestone. I was considering that but we don't have 7.14 milestone yet.

...

Just curious, is there a way to keep these functions for backwards compat in 7.14 or is that unfeasible? They could stay, technically that's not a problem. But I'm adding new functions that can do the same thing (and more), so we have redundancy.

Can you hide them in the haddock but leave in the module, so that we don't break existing code?

I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with #if MIN_VERSION_template_haskell(X,Y,X) -- new way #else -- old way #endif for 3+ years (which is typically how many GHC versions popular libraries try to support).

On 2015-01-09 at 11:18:02 +0100, Jan Stolarek wrote:

The reall question is how to remember that we should remove this at some point?

This affects all exposed libraries; I think it's enough to simply make this part of the release-procedure at some point in the release-cycle, to actively scan all DEPRECATIONs, and decide for each whether to kill them or let them live for another cycle. It simplifies things though, if it's obvious when a deprecation was declared so one doesn't have to `git blame` for it. Many deprecations already have a comment attached like "deprecated in GHC x.y"

On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek wrote:

...

I agree. You'll get rid of the redundancy in the library by removing it but you're users will have to live with (...) That's why I want to deprecate them first and give users one release cycle to switch to new functions. I assumed that's enough but we could make this two or three release cycles. The reall question is how to remember that we should remove this at some point?

If we want to avoid the CPP we need warning to be in major version X if that's when the old function is deprecated and the new one is added and the actual removal in X+2. At that point I'd just consider keeping the function and avoid the hassle. :)

On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel wrote:

Why hide them? DEPRECATEd entities have the deprecation-message shown in discouraging red letters (including any hyperlinks to their replacements) in the generated Haddock documentation...

I think Java's (!) policy for deprecation is good: Deprecation is (mostly) for functions that are error prone or otherwise dangerous. Unless the cost of keeping the function is large, removing functions should be avoided. The docs can point to the newer functions, but DEPRECATION pragmas will just add noise to users' compiles.

On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek wrote:

...

I think Java's (!) policy for deprecation is good I think it's not. It keeps the library code a mess and many times I have seen users using functions that have been deprecated for years just because it's easier to suppress a warning than change the code. I don't want Haskell to go down that path and I'm strongly in favour of removing these functions. Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users.

It also keeps Java having users. ;) More seriously, we who maintain the core libraries spend too much time dealing with breakages due to continuously moving libraries when we could spend time on building upwards to make Haskell a better platform for building applications. *In practice* our code is worse because of these continuous breakages (as it's full with hard to maintain CPP), not better.

I agree with Johan. I do think it makes sense to remove deprecated/replaced functions, but only after N+2 cycles. On 06:18, Fri, Jan 9, 2015 Richard Eisenberg wrote:

On Jan 9, 2015, at 5:37 AM, Jan Stolarek wrote:

...

Especially that we're talking about internal TH module - I'll be surprised if there are more than 10 users.

As I understand it, TH.Lib is not an internal module. Though I, personally, have never found the functions there to suit my needs as a user, I think the functions exported from there are the go-to place for lots of people using TH. For example, Ollie Charles's recent blog post on TH (https://ocharles.org.uk/blog/guest-posts/2014-12-22- template-haskell.html), written by Sean Westfall, uses functions exported from TH.Lib.

I'm rather ambivalent on the deprecate vs. remove vs. hide vs. leave alone debate, but I do think we should treat TH.Lib as a fully public module as we're debating.

Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Can you hide them in the haddock but leave in the module, so that we don't break existing code? Not sure. These functions are in Language.Haskell.TH.Lib module and functions there are not haddockified at all. I initially thought this module is internal but Richard told me that people are actually using functions from that module and there were complaints from the users when he removed some functions from there.

Janek