Shared data type for extension flags

[malcolm.wallace]

"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" <ezyang at mit.edu> 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:michael at 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 at microsoft.com<mailto:simonpj at 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 at haskell.org<mailto:ghc-devs-bounces at 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 at gmail.com<mailto:matthewtpickering at 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 at diglumi.com<mailto:michael at 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-Extension.html
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20150910/946f253e/attachment.html>