classP recently deleted from TH.Lib

newer
Questions about "time and space...

Gabor Greif

12 May 2014 12 May '14

2:12 p.m.

The last two commits from (Apr 9) on https://github.com/ghc/packages-template-haskell/commits/master/Language/Has... removed a helper to construct applied type class constraints (`classP`). Some packages (notably `llvm-general-pure`) though, depend on it. Can we add back something like this: {{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}} and export it again? Or is there such a helper with a different name already? Cheers, Gabor

Show replies by date

Johan Tibell

12 May 12 May

2:35 p.m.

That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries. On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote:

...

The last two commits from (Apr 9) on

< https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

...
removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

Gabor Greif

2:51 p.m.

Forgot to explicitly state that this is with 7.9 HEAD. 7.8.2 is delivered with template-haskell 2.9.0.0, which contains the `classP` helper. Richard, if you also support my suggestion, I'll go forward and push it. Cheers, Gabor On 5/12/14, Johan Tibell wrote:

...

That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries.

On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote:

...
The last two commits from (Apr 9) on

< https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

...
removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

Simon Peyton Jones

2:51 p.m.

I suspect it was accidental, but Richard will doubtless say in due course Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Johan Tibell Sent: 12 May 2014 15:35 To: Gabor Greif Cc: ghc-devs Subject: Re: classP recently deleted from TH.Lib That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries. On Mon, May 12, 2014 at 4:12 PM, Gabor Greif mailto:ggreif@gmail.com> wrote: The last two commits from (Apr 9) on https://github.com/ghc/packages-template-haskell/commits/master/Language/Has... removed a helper to construct applied type class constraints (`classP`). Some packages (notably `llvm-general-pure`) though, depend on it. Can we add back something like this: {{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}} and export it again? Or is there such a helper with a different name already? Cheers, Gabor _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Richard Eisenberg

2:58 p.m.

This one was my fault/decision. The TH.Lib functions tend to mirror exactly the constructors in TH.Syntax. We removed the constructors (for good reason -- predicates and types really are the same now), so I thought it best to remove the TH.Lib function, too. In the cases where code had to be updated, would keeping classP in be enough to prevent the breakage? We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time. Here are some ideas for this, and other similar situations, going forward: 1) Don't remove functions from TH.Lib unless absolutely necessary (which should probably never happen). 2) Remove functions from TH.Lib, but support some other package ("th-compat") which fills in the compatibility gap. This package would not be tied in with GHC. It would use CPP to export functions in order to remain compatible with a range of GHC versions. In this example, the package would export a fresh classP in 7.9+ but just re-export TH's in 7.8-. 3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to users to sort it out as they see fit. It is worth noting that a change of this sort in TH.Lib corresponds to a breaking change in TH.Syntax. But, perhaps most people rely on Lib and not on Syntax. I'm happy to follow what the community thinks is best here -- I don't have any vested opinion. Thanks -- and sorry for the breakage! Richard On May 12, 2014, at 10:35 AM, Johan Tibell wrote:

...

That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries.

On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote: The last two commits from (Apr 9) on

https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

Gabor Greif

10:33 p.m.

On 5/12/14, Richard Eisenberg wrote:

...

This one was my fault/decision. The TH.Lib functions tend to mirror exactly the constructors in TH.Syntax. We removed the constructors (for good reason

Hmmm, okay, I see you added `equalityT` which is just a shallow wrapper around a new constructor.

...

-- predicates and types really are the same now), so I thought it best to remove the TH.Lib function, too. In the cases where code had to be updated, would keeping classP in be enough to prevent the breakage?

Cannot speak for many packages, but adding `classP` back would make llvm-general-pure compilable again with HEAD. Maybe we could add it back and mark it as deprecated?

...

We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I see no serious drawbacks with an explicitly deprecated API.

...

Here are some ideas for this, and other similar situations, going forward: 1) Don't remove functions from TH.Lib unless absolutely necessary (which should probably never happen). 2) Remove functions from TH.Lib, but support some other package ("th-compat") which fills in the compatibility gap. This package would not be tied in with GHC. It would use CPP to export functions in order to remain compatible with a range of GHC versions. In this example, the package would export a fresh classP in 7.9+ but just re-export TH's in 7.8-.

This sounds like a good idea, but the dependent packages would need to adopt this scheme. I.e. import `classP` from th-compat, and hiding `classP` from import TH.Lib. Not sure what the best practices are. Anyway, if this scheme works, one could remove TH.Lib.classP from GHC 7.12.

...

3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to users to sort it out as they see fit.

This would imply that some packages need to perform preprocessor conditional compilation to include `classP`. IMHO the worst option, as it causes duplication. Just my few cents. Cheers, Gabor

...

It is worth noting that a change of this sort in TH.Lib corresponds to a breaking change in TH.Syntax. But, perhaps most people rely on Lib and not on Syntax.

I'm happy to follow what the community thinks is best here -- I don't have any vested opinion.

Thanks -- and sorry for the breakage! Richard

On May 12, 2014, at 10:35 AM, Johan Tibell wrote:

...
That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries.

On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote: The last two commits from (Apr 9) on

https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

Mateusz Kowalczyk

13 May 13 May

7:19 p.m.

On 05/13/2014 12:33 AM, Gabor Greif wrote:

...

On 5/12/14, Richard Eisenberg wrote:

...
This one was my fault/decision. The TH.Lib functions tend to mirror exactly the constructors in TH.Syntax. We removed the constructors (for good reason

Hmmm, okay, I see you added `equalityT` which is just a shallow wrapper around a new constructor.

...
-- predicates and types really are the same now), so I thought it best to remove the TH.Lib function, too. In the cases where code had to be updated, would keeping classP in be enough to prevent the breakage?

Cannot speak for many packages, but adding `classP` back would make llvm-general-pure compilable again with HEAD. Maybe we could add it back and mark it as deprecated?

Why not simply patch llvm-general-pure? I have done this with quite a few packages when the TH change was made and it seems to work. If anything, it will make the authors realise something changed upstream and try to find out how.

...

...
We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I see no serious drawbacks with an explicitly deprecated API.

...
Here are some ideas for this, and other similar situations, going forward: 1) Don't remove functions from TH.Lib unless absolutely necessary (which should probably never happen). 2) Remove functions from TH.Lib, but support some other package ("th-compat") which fills in the compatibility gap. This package would not be tied in with GHC. It would use CPP to export functions in order to remain compatible with a range of GHC versions. In this example, the package would export a fresh classP in 7.9+ but just re-export TH's in 7.8-.

This sounds like a good idea, but the dependent packages would need to adopt this scheme. I.e. import `classP` from th-compat, and hiding `classP` from import TH.Lib.

Not sure what the best practices are. Anyway, if this scheme works, one could remove TH.Lib.classP from GHC 7.12.

...
3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to users to sort it out as they see fit.

This would imply that some packages need to perform preprocessor conditional compilation to include `classP`. IMHO the worst option, as it causes duplication.

I think this is a fair solution until TH 2.9 is phased out.

...

Just my few cents.

Cheers,

Gabor

...
It is worth noting that a change of this sort in TH.Lib corresponds to a breaking change in TH.Syntax. But, perhaps most people rely on Lib and not on Syntax.

I'm happy to follow what the community thinks is best here -- I don't have any vested opinion.

Thanks -- and sorry for the breakage! Richard

On May 12, 2014, at 10:35 AM, Johan Tibell wrote:

...
That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries.

On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote: The last two commits from (Apr 9) on

https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

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

-- Mateusz K.

Carter Schonwald

8:11 p.m.

i'm quite certain BScarlet will accept patches to fix up llvm-general-pure for ghc head. Hes a very responsive author On Mon, May 12, 2014 at 6:33 PM, Gabor Greif wrote:

...

On 5/12/14, Richard Eisenberg wrote:

...
This one was my fault/decision. The TH.Lib functions tend to mirror exactly the constructors in TH.Syntax. We removed the constructors (for good reason

Hmmm, okay, I see you added `equalityT` which is just a shallow wrapper around a new constructor.

...
-- predicates and types really are the same now), so I thought it best to remove the TH.Lib function, too. In the cases where code had to be updated, would keeping classP in be enough to prevent the breakage?

Cannot speak for many packages, but adding `classP` back would make llvm-general-pure compilable again with HEAD. Maybe we could add it back and mark it as deprecated?

...
We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I see no serious drawbacks with an explicitly deprecated API.

...
Here are some ideas for this, and other similar situations, going

forward:

...
1) Don't remove functions from TH.Lib unless absolutely necessary (which should probably never happen). 2) Remove functions from TH.Lib, but support some other package ("th-compat") which fills in the compatibility gap. This package would not be tied in with GHC. It would use CPP to export functions in order to remain compatible with a range of GHC versions. In this example, the package would export a fresh classP in 7.9+ but just re-export TH's in 7.8-.

This sounds like a good idea, but the dependent packages would need to adopt this scheme. I.e. import `classP` from th-compat, and hiding `classP` from import TH.Lib.

Not sure what the best practices are. Anyway, if this scheme works, one could remove TH.Lib.classP from GHC 7.12.

...
3) Do what I've done -- keep TH.Lib parallel with TH.Syntax and leave it to users to sort it out as they see fit.

This would imply that some packages need to perform preprocessor conditional compilation to include `classP`. IMHO the worst option, as it causes duplication.

Just my few cents.

Cheers,

Gabor

...
It is worth noting that a change of this sort in TH.Lib corresponds to a breaking change in TH.Syntax. But, perhaps most people rely on Lib and

not

...
on Syntax.

I'm happy to follow what the community thinks is best here -- I don't have any vested opinion.

Thanks -- and sorry for the breakage! Richard

On May 12, 2014, at 10:35 AM, Johan Tibell wrote:

...
That would be nice. I had to fix some breakage caused by this in one of Bryan's libraries.

On Mon, May 12, 2014 at 4:12 PM, Gabor Greif wrote: The last two commits from (Apr 9) on

< https://github.com/ghc/packages-template-haskell/commits/master/Language/Has...

...
removed a helper to construct applied type class constraints (`classP`).

Some packages (notably `llvm-general-pure`) though, depend on it.

Can we add back something like this:

{{{ classP :: Name -> [Q Type] -> Q Pred classP cla tys = do tysl <- sequence tys return (foldl' AppT (ConT cla) tysl) }}}

and export it again? Or is there such a helper with a different name already?

Cheers,

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

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

Gregory Collins

14 May 14 May

3:53 p.m.

On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg wrote:

...

We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I think the ultimate goal of removing the function was not unwise of you, but the right thing to do here would be to write a reimplementation, mark it as {-# DEPRECATED #-}, and give a timetable for its future removal. This gives users time to adjust and minimizes breakage. G -- Gregory Collins

Gabor Greif

9:40 p.m.

Alrighty, this is what I have now. If you think this is ok, I'll go on re-implementing equalP too and commit. Then we can bikeshed about the deprecation message :-) diff --git a/libraries/template-haskell/Language/Haskell/TH/Lib.hs b/libraries/template-haskell/Language/Haskell/TH/Lib.hs index 49baa96..08235ba 100644 --- a/libraries/template-haskell/Language/Haskell/TH/Lib.hs +++ b/libraries/template-haskell/Language/Haskell/TH/Lib.hs @@ -526,6 +526,13 @@ sigT t k equalityT :: TypeQ equalityT = return EqualityT +{-# DEPRECATED classP "Constraint constructors are just type constructors, frob this code as 'constraintT'." #-} +classP :: Name -> [Q Type] -> Q Pred +classP cla tys + = do + tysl <- sequence tys + return (foldl AppT (ConT cla) tysl) + promotedT :: Name -> TypeQ promotedT = return . PromotedT Cheers, Gabor On 5/14/14, Gregory Collins wrote:

...

On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg wrote:

...
We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I think the ultimate goal of removing the function was not unwise of you, but the right thing to do here would be to write a reimplementation, mark it as {-# DEPRECATED #-}, and give a timetable for its future removal. This gives users time to adjust and minimizes breakage.

G -- Gregory Collins

Gabor Greif

19 May 19 May

8:55 p.m.

All, just pushed 4117551 and 135489d. Any feedback appreciated. Cheers, Gabor On 5/14/14, Gabor Greif wrote:

...

Alrighty, this is what I have now. If you think this is ok, I'll go on re-implementing equalP too and commit. Then we can bikeshed about the deprecation message :-)

diff --git a/libraries/template-haskell/Language/Haskell/TH/Lib.hs b/libraries/template-haskell/Language/Haskell/TH/Lib.hs index 49baa96..08235ba 100644 --- a/libraries/template-haskell/Language/Haskell/TH/Lib.hs +++ b/libraries/template-haskell/Language/Haskell/TH/Lib.hs @@ -526,6 +526,13 @@ sigT t k equalityT :: TypeQ equalityT = return EqualityT

+{-# DEPRECATED classP "Constraint constructors are just type constructors, frob this code as 'constraintT'." #-} +classP :: Name -> [Q Type] -> Q Pred +classP cla tys + = do + tysl <- sequence tys + return (foldl AppT (ConT cla) tysl) + promotedT :: Name -> TypeQ promotedT = return . PromotedT

Cheers,

Gabor

On 5/14/14, Gregory Collins wrote:

...
On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg wrote:

...
We could, of course, just leave the functions there with new implementations, but that feels like it could accumulate legacy functions over time.

I think the ultimate goal of removing the function was not unwise of you, but the right thing to do here would be to write a reimplementation, mark it as {-# DEPRECATED #-}, and give a timetable for its future removal. This gives users time to adjust and minimizes breakage.

G -- Gregory Collins

4153

Age (days ago)

4160

Last active (days ago)

List overview

Download

10 comments

7 participants

participants (7)

Carter Schonwald
Gabor Greif
Gregory Collins
Johan Tibell
Mateusz Kowalczyk
Richard Eisenberg
Simon Peyton Jones