Re: classP recently deleted from TH.Lib
All,
just pushed 4117551 and 135489d.
Any feedback appreciated.
Cheers,
Gabor
On 5/14/14, Gabor Greif ggr...@gmail.com 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 g...@gregorycollins.net wrote:
On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg
e...@cis.upenn.eduwrote:
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 g...@gregorycollins.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg e...@cis.upenn.eduwrote:
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 g...@gregorycollins.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
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 g...@gregorycollins.net wrote:
On Mon, May 12, 2014 at 4:58 PM, Richard Eisenberg
e...@cis.upenn.eduwrote:
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 g...@gregorycollins.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
On 05/13/2014 12:33 AM, Gabor Greif wrote:
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu 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 johan.tib...@gmail.com 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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
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 ggr...@gmail.com wrote:
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu 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 johan.tib...@gmail.com
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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
classP recently deleted from TH.Lib
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
Re: classP recently deleted from TH.Lib
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 johan.tib...@gmail.com 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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
RE: classP recently deleted from TH.Lib
I suspect it was accidental, but Richard will doubtless say in due course
Simon
From: ghc-devs [mailto:ghc-devs-boun...@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
ggr...@gmail.commailto:ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: classP recently deleted from TH.Lib
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 johan.tib...@gmail.com 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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
Re: classP recently deleted from TH.Lib
On 5/12/14, Richard Eisenberg e...@cis.upenn.edu 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 johan.tib...@gmail.com 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 ggr...@gmail.com wrote:
The last two commits from (Apr 9) on
https://github.com/ghc/packages-template-haskell/commits/master/Language/Haskell/TH/Lib.hs
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
