Shared data type for extension flags
Alan & Kim Zimmerman
alan.zimm at gmail.com
Wed Sep 2 18:39:33 UTC 2015
Would this be a feasible approach for harmonising the AST between GHC and
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>
>> we already have such a shared library, I think: bin-package-db. would
>> that do?
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Michael
>> *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
>> 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>
>> > #10820 on Trac  and D1200 on Phabricator  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
>> > There is a second data type encoding the list of possible language
>> > extensions in
>> > the Cabal package, in Language.Haskell.Extension . But
>> > 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
>> > list
>> > in two more places, to convert back and forth between the TH Extension
>> > type
>> > and GHC's internal ExtensionFlag data type.
>> > Is there another way here? Can there be one single shared data type for
>> > somehow?
>> >  https://ghc.haskell.org/trac/ghc/ticket/10820
>> >  https://phabricator.haskell.org/D1200
>> > 
>> > _______________________________________________
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs