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 e...@cis.upenn.edu wrote:
On Jan 9, 2015, at 5:37 AM, Jan Stolarek jan.stola...@p.lodz.pl wrote:
Especially that we're talking
We could file a tracking bug against the 7.14 milestone.
Just curious, is there a way to keep these functions for backwards compat
in 7.14 or is that unfeasible?
On Fri, Jan 9, 2015 at 10:22 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:
I want to deprecate some Template Haskell functions in
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
On 2015-01-09 at 11:09:07 +0100, Roman Cheplyaka wrote:
[...]
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
On Fri, Jan 9, 2015 at 11:09 AM, Roman Cheplyaka r...@ro-che.info 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
On Fri, Jan 9, 2015 at 11:13 AM, Herbert Valerio Riedel hvrie...@gmail.com
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 (!)
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
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
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
On 2015-01-09 11:25, Herbert Valerio Riedel wrote:
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
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
On Jan 9, 2015, at 5:37 AM, Jan Stolarek jan.stola...@p.lodz.pl 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
On Fri, Jan 9, 2015 at 11:18 AM, Jan Stolarek jan.stola...@p.lodz.pl
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
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
On Fri, Jan 9, 2015 at 11:37 AM, Jan Stolarek jan.stola...@p.lodz.pl
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
15 matches
Mail list logo
