Shared data type for extension flags

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Shared data type for extension flags

Michael Smith
#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-Extension.html

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Matthew Pickering
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 <[hidden email]> 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-Extension.html
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Michael Smith
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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Shared data type for extension flags

Simon Peyton Jones

we already have such a shared library, I think: bin-package-db.  would that do?

 

Simon

 

From: ghc-devs [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>

> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Michael Smith

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 <[hidden email]> wrote:

we already have such a shared library, I think: bin-package-db.  would that do?

 

Simon

 

From: ghc-devs [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>

> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Alan & Kim Zimmerman

Would this be a feasible approach for harmonising the AST between GHC and TH too?

Alan

On 2 Sep 2015 09:27, "Michael Smith" <[hidden email]> 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 <[hidden email]> wrote:

we already have such a shared library, I think: bin-package-db.  would that do?

 

Simon

 

From: ghc-devs [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>

> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Michael Smith

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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> wrote:

we already have such a shared library, I think: bin-package-db.  would that do?

 

Simon

 

From: ghc-devs [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>

> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Herbert Valerio Riedel-3
In reply to this post by Matthew Pickering
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/Extension.hs

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.
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Reid Barton-2
On Thu, Sep 3, 2015 at 12:41 PM, Herbert Valerio Riedel <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Shared data type for extension flags

Simon Peyton Jones
In reply to this post by Michael Smith

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:[hidden email]]
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 <[hidden email]> wrote:

we already have such a shared library, I think: bin-package-db.  would that do?

 

Simon

 

From: ghc-devs [mailto:[hidden email]] 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 <[hidden email]> 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 <[hidden email]> 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-Extension.html
>

> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

 


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Shared data type for extension flags

Edward Z. Yang
I don't think it makes very much sense to reuse bin-package-db; at
least, not without renaming it at the very least (who'd expect
a list of language extension flags to live in a binary package
database?)  We could name it something like 'ghc-types'?

Edward

Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700:

> 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:[hidden email]]
> 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 <[hidden email]<mailto:[hidden email]>> wrote:
> we already have such a shared library, I think: bin-package-db.  would that do?
>
> Simon
>
> From: ghc-devs [mailto:[hidden email]<mailto:[hidden email]>] 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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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-Extension.html
> >
> > _______________________________________________
> > ghc-devs mailing list
> > [hidden email]<mailto:[hidden email]>
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Malcolm Wallace-2
In reply to this post by Michael Smith
"ghc-types" sounds like a package for fancy type hackery.  I would never think to find language extension flags in such a place.  How about "ghc-package-db", or "ghc-language-extensions"?
Regards,
    Malcolm

On 10 Sep, 2015,at 03:30 AM, "Edward Z. Yang" <[hidden email]> wrote:

I don't think it makes very much sense to reuse bin-package-db; at
least, not without renaming it at the very least (who'd expect
a list of language extension flags to live in a binary package
database?) We could name it something like 'ghc-types'?

Edward

Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700:
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:[hidden email]]
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 <[hidden email]<mailto:[hidden email]>> wrote:
we already have such a shared library, I think: bin-package-db. would that do?

Simon

From: ghc-devs [mailto:[hidden email]<mailto:[hidden email]>] 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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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-Extension.html
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]<mailto:[hidden email]>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Brandon Allbery
On Thu, Sep 10, 2015 at 4:28 AM, malcolm.wallace <[hidden email]> wrote:
"ghc-types" sounds like a package for fancy type hackery.  I would never think to find language extension flags in such a place.  How about "ghc-package-db", or "ghc-language-extensions"?

ghc-integration
ghc-core-data

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Shared data type for extension flags

Adam Sandberg Eriksson
How about ghc-datatypes?
 
ghc-core-data seems like it would have something to do with the Core language and ghc-integration sounds like it is a layer on top of ghc.
 
Using the -types suffix has quite som precedence [1] for packages defining shared datatypes (as does the -core suffix), but given Malcolms comment it is perhaps not a good fit for GHC.
 
 
Adam Sandberg Eriksson
 
 
On Thu, 10 Sep 2015, at 05:50 PM, Brandon Allbery wrote:
On Thu, Sep 10, 2015 at 4:28 AM, malcolm.wallace <[hidden email]> wrote:
"ghc-types" sounds like a package for fancy type hackery.  I would never think to find language extension flags in such a place.  How about "ghc-package-db", or "ghc-language-extensions"?
 
ghc-integration
ghc-core-data
 
--
brandon s allbery kf8nh                               sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
_______________________________________________
ghc-devs mailing list
 

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs