#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user. There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately. So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type. Is there another way here? Can there be one single shared data type for this somehow? [1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3] https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration. On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3] https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type? On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < matthewtpickering@gmail.com> wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3]
https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
we already have such a shared library, I think: bin-package-db. would that do? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Michael Smith Sent: 02 September 2015 09:21 To: Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type? On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> wrote: Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration. On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com<mailto:michael@diglumi.com>> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3] https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway? On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj@microsoft.com> wrote:
we already have such a shared library, I think: bin-package-db. would that do?
Simon
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Michael Smith *Sent:* 02 September 2015 09:21 *To:* Matthew Pickering *Cc:* GHC developers *Subject:* Re: Shared data type for extension flags
That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type?
On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < matthewtpickering@gmail.com> wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3]
https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Would this be a feasible approach for harmonising the AST between GHC and TH too? Alan On 2 Sep 2015 09:27, "Michael Smith" <michael@diglumi.com> wrote:
The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway?
On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj@microsoft.com> wrote:
we already have such a shared library, I think: bin-package-db. would that do?
Simon
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Michael Smith *Sent:* 02 September 2015 09:21 *To:* Matthew Pickering *Cc:* GHC developers *Subject:* Re: Shared data type for extension flags
That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type?
On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < matthewtpickering@gmail.com> wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3]
https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
I don't know about the entire AST. GHC's AST contains a lot of complexity that one wouldn't want to expose at the TH level. And the separation allows GHC to change the internal AST around while maintaining a stable interface for packages depending on TH. That said, there are some bits that I could see being shared. Fixity and Strict from TH come to mind. On Wed, Sep 2, 2015, 11:39 Alan & Kim Zimmerman <alan.zimm@gmail.com> wrote:
Would this be a feasible approach for harmonising the AST between GHC and TH too?
Alan On 2 Sep 2015 09:27, "Michael Smith" <michael@diglumi.com> wrote:
The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway?
On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj@microsoft.com> wrote:
we already have such a shared library, I think: bin-package-db. would that do?
Simon
*From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Michael Smith *Sent:* 02 September 2015 09:21 *To:* Matthew Pickering *Cc:* GHC developers *Subject:* Re: Shared data type for extension flags
That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type?
On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering < matthewtpickering@gmail.com> wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3]
https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Yes, we’d have to broaden the description of the package. I defer to Edward Yang and Duncan Coutts who have a clearer idea of the architecture in this area. Simon From: Michael Smith [mailto:michael@diglumi.com] Sent: 02 September 2015 17:27 To: Simon Peyton Jones; Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags The package description for that is "The GHC compiler's view of the GHC package database format", and this doesn't really have to do with the package database format. Would it be okay to put this in there anyway? On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> wrote: we already have such a shared library, I think: bin-package-db. would that do? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Michael Smith Sent: 02 September 2015 09:21 To: Matthew Pickering Cc: GHC developers Subject: Re: Shared data type for extension flags That sounds like a good approach. Are there other things that would go nicely in a shared package like this, in addition to the extension data type? On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> wrote: Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration. On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com<mailto:michael@diglumi.com>> wrote:
#10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the capababilty to Template Haskell to detect which language extensions enabled. Unfortunately, since template-haskell can't depend on ghc (as ghc depends on template-haskell), it can't simply re-export the ExtensionFlag type from DynFlags to the user.
There is a second data type encoding the list of possible language extensions in the Cabal package, in Language.Haskell.Extension [3]. But template-haskell doesn't already depend on Cabal, and doing so seems like it would cause difficulties, as the two packages can be upgraded separately.
So adding this new feature to Template Haskell requires introducing a *third* data type for language extensions. It also requires enumerating this full list in two more places, to convert back and forth between the TH Extension data type and GHC's internal ExtensionFlag data type.
Is there another way here? Can there be one single shared data type for this somehow?
[1] https://ghc.haskell.org/trac/ghc/ticket/10820 [2] https://phabricator.haskell.org/D1200 [3] https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Ext...
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
I'm not sure this is such a good idea having a package many packages depend on if `ghc` is one of them, as this forces every install-plan which ends up involving the ghc package to be pinned to the very same version the `ghc` package was compiled against. This is a general problem affecting packages `ghc` depends upon (and as a side-note starting with GHC 7.10, we were finally able to cut the package-dependency between `ghc` and `Cabal`) Also, Cabal is not GHC specific, and contains a list of known extensions (`KnownExtension`) across multiple Haskell compilers https://github.com/haskell/cabal/blob/master/Cabal/Language/Haskell/Extensio... and I assume the extension enumeration needed for GHC would be tailored to GHC's need and omit extensions not relevant to GHC, as well as include experimental/internal ones not suited for consumption by Cabal.
On Thu, Sep 3, 2015 at 12:41 PM, Herbert Valerio Riedel <hvriedel@gmail.com> wrote:
On 2015-09-02 at 10:00:40 +0200, Matthew Pickering wrote:
Surely the easiest way here (including for other tooling - ie haskell-src-exts) is to create a package which just provides this enumeration. GHC, cabal, th, haskell-src-exts and so on then all depend on this package rather than creating their own enumeration.
I'm not sure this is such a good idea having a package many packages depend on if `ghc` is one of them, as this forces every install-plan which ends up involving the ghc package to be pinned to the very same version the `ghc` package was compiled against.
This is a general problem affecting packages `ghc` depends upon (and as a side-note starting with GHC 7.10, we were finally able to cut the package-dependency between `ghc` and `Cabal`)
Surely this argument does not apply to a package created to hold data types that would otherwise live in the template-haskell or ghc packages. Regards, Reid Barton
participants (6)
-
Alan & Kim Zimmerman -
Herbert Valerio Riedel -
Matthew Pickering -
Michael Smith -
Reid Barton -
Simon Peyton Jones