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" <michael at 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 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] *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> 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>
>> 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
>> > 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/20150902/ac537794/attachment.html>