<div dir="ltr">On Fri, Sep 25, 2015 at 12:18 PM, Eric Seidel <span dir="ltr"><<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been meaning to ask about this as well. It also forces tools like<br>
ghc-mod and hdevtools to be cabal-aware, which is an unnecessary source<br>
of complexity IMO.<br></blockquote><div><br></div><div>This would certainly be nice, but... <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
GHC certainly has enough information to generate these macros, as it<br>
knows which packages (and versions) it's compiling against.<br></blockquote><div><br></div><div>It knows at some point, but it doesn't necessarily know before parsing the module, at which point it is too late. I can have two versions of a package A, and two other packages B and C that depend on different versions of A, and depending on whether a module M uses package B or package C, M will see different versions of package A automatically. This is all slightly magical, and I have to say I don't entirely understand how GHC decides which versions to expose in general, but that's how GHC works today and it's quite convenient.<br><br></div><div>GHC could provide MIN_VERSION_* macros for packages that have had their versions specified with -package or similar flags (which is how Cabal invokes GHC). That would go only a small way towards the original goals though.<br><br></div><div>(Also, I wonder how MIN_VERSION_* fits into a Backpack world...)<br></div><div><br></div><div>Regards,<br></div><div>Reid Barton<br></div></div></div></div>