<html><body><div>"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"?</div><div class="x-apple-signature"><pre style="font-family: 'Helvetica Neue', Helvetica, sans-serif; font-size: 15px; white-space: pre-wrap; word-wrap: break-word;" data-mce-style="font-family: 'Helvetica Neue', Helvetica, sans-serif; font-size: 15px; white-space: pre-wrap; word-wrap: break-word;">Regards,
Malcolm</pre></div><div><br>On 10 Sep, 2015,at 03:30 AM, "Edward Z. Yang" <ezyang@mit.edu> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content">I don't think it makes very much sense to reuse bin-package-db; at<br>least, not without renaming it at the very least (who'd expect<br>a list of language extension flags to live in a binary package<br>database?) We could name it something like 'ghc-types'?<br><br>Edward<br><br>Excerpts from Simon Peyton Jones's message of 2015-09-08 05:35:00 -0700:<br></span></span><blockquote class="quoted-plain-text" type="cite">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.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">Simon</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">From: Michael Smith [mailto:michael@diglumi.com]</blockquote><blockquote class="quoted-plain-text" type="cite">Sent: 02 September 2015 17:27</blockquote><blockquote class="quoted-plain-text" type="cite">To: Simon Peyton Jones; Matthew Pickering</blockquote><blockquote class="quoted-plain-text" type="cite">Cc: GHC developers</blockquote><blockquote class="quoted-plain-text" type="cite">Subject: Re: Shared data type for extension flags</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">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?</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">On Wed, Sep 2, 2015, 07:33 Simon Peyton Jones <simonpj@microsoft.com<mailto:simonpj@microsoft.com>> wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">we already have such a shared library, I think: bin-package-db. would that do?</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">Simon</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of Michael Smith</blockquote><blockquote class="quoted-plain-text" type="cite">Sent: 02 September 2015 09:21</blockquote><blockquote class="quoted-plain-text" type="cite">To: Matthew Pickering</blockquote><blockquote class="quoted-plain-text" type="cite">Cc: GHC developers</blockquote><blockquote class="quoted-plain-text" type="cite">Subject: Re: Shared data type for extension flags</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">That sounds like a good approach. Are there other things that would go nicely</blockquote><blockquote class="quoted-plain-text" type="cite">in a shared package like this, in addition to the extension data type?</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">On Wed, Sep 2, 2015 at 1:00 AM, Matthew Pickering <matthewtpickering@gmail.com<mailto:matthewtpickering@gmail.com>> wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">Surely the easiest way here (including for other tooling - ie</blockquote><blockquote class="quoted-plain-text" type="cite">haskell-src-exts) is to create a package which just provides this</blockquote><blockquote class="quoted-plain-text" type="cite">enumeration. GHC, cabal, th, haskell-src-exts and so on then all</blockquote><blockquote class="quoted-plain-text" type="cite">depend on this package rather than creating their own enumeration.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">On Wed, Sep 2, 2015 at 9:47 AM, Michael Smith <michael@diglumi.com<mailto:michael@diglumi.com>> wrote:</blockquote><blockquote class="quoted-plain-text" type="cite">> #10820 on Trac [1] and D1200 on Phabricator [2] discuss adding the</blockquote><blockquote class="quoted-plain-text" type="cite">> capababilty</blockquote><blockquote class="quoted-plain-text" type="cite">> to Template Haskell to detect which language extensions enabled.</blockquote><blockquote class="quoted-plain-text" type="cite">> Unfortunately,</blockquote><blockquote class="quoted-plain-text" type="cite">> since template-haskell can't depend on ghc (as ghc depends on</blockquote><blockquote class="quoted-plain-text" type="cite">> template-haskell),</blockquote><blockquote class="quoted-plain-text" type="cite">> it can't simply re-export the ExtensionFlag type from DynFlags to the user.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> There is a second data type encoding the list of possible language</blockquote><blockquote class="quoted-plain-text" type="cite">> extensions in</blockquote><blockquote class="quoted-plain-text" type="cite">> the Cabal package, in Language.Haskell.Extension [3]. But template-haskell</blockquote><blockquote class="quoted-plain-text" type="cite">> doesn't already depend on Cabal, and doing so seems like it would cause</blockquote><blockquote class="quoted-plain-text" type="cite">> difficulties, as the two packages can be upgraded separately.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> So adding this new feature to Template Haskell requires introducing a</blockquote><blockquote class="quoted-plain-text" type="cite">> *third*</blockquote><blockquote class="quoted-plain-text" type="cite">> data type for language extensions. It also requires enumerating this full</blockquote><blockquote class="quoted-plain-text" type="cite">> list</blockquote><blockquote class="quoted-plain-text" type="cite">> in two more places, to convert back and forth between the TH Extension data</blockquote><blockquote class="quoted-plain-text" type="cite">> type</blockquote><blockquote class="quoted-plain-text" type="cite">> and GHC's internal ExtensionFlag data type.</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> Is there another way here? Can there be one single shared data type for this</blockquote><blockquote class="quoted-plain-text" type="cite">> somehow?</blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> [1] <a href="https://ghc.haskell.org/trac/ghc/ticket/10820" data-mce-href="https://ghc.haskell.org/trac/ghc/ticket/10820">https://ghc.haskell.org/trac/ghc/ticket/10820</a></blockquote><blockquote class="quoted-plain-text" type="cite">> [2] <a href="https://phabricator.haskell.org/D1200" data-mce-href="https://phabricator.haskell.org/D1200">https://phabricator.haskell.org/D1200</a></blockquote><blockquote class="quoted-plain-text" type="cite">> [3]</blockquote><blockquote class="quoted-plain-text" type="cite">> <a href="https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html" data-mce-href="https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html">https://hackage.haskell.org/package/Cabal-1.22.4.0/docs/Language-Haskell-Extension.html</a></blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><blockquote class="quoted-plain-text" type="cite">> _______________________________________________</blockquote><blockquote class="quoted-plain-text" type="cite">> ghc-devs mailing list</blockquote><blockquote class="quoted-plain-text" type="cite">> <a href="mailto:ghc-devs@haskell.org" data-mce-href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><mailto:ghc-devs@haskell.org></blockquote><blockquote class="quoted-plain-text" type="cite">> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" data-mce-href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a></blockquote><blockquote class="quoted-plain-text" type="cite">></blockquote><span class="body-text-content">_______________________________________________<br>ghc-devs mailing list<br><a href="mailto:ghc-devs@haskell.org" data-mce-href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" data-mce-href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br></span></div></div></blockquote></div></body></html>