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 <alan.zimm at 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 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/c7b4e771/attachment.html>