ExplicitForAll errors, even when RankNTypes is enabled about argon HOT 10 CLOSED

Nice work! It could be that Argon is setting extensions in a wrong way and impliedXFlags is never called.
The link to the GHC source is super useful! 👍

from argon.

Got it! Argon should use setExtensionFlag' instead of xopt_set. The former is exactly what we need:
https://github.com/ghc/ghc/blob/master/compiler/main/DynFlags.hs#L4175
because it calls impliedXFlags automatically.

The problem is.... it isn't exported 😧 And we cannot even implement it ourselves, because neither impliedXFlags is exported. We would then have to copy everything, but I really dislike this solution as implied extensions can change between different GHC versions.

The odd thing is that setGeneralFlags' is exported. It really seems like they forgot to export setExtensionFlag'.

from argon.

That is unfortunate, indeed. So, the copying solution is ugly, but is probably the only thing we can hope to have before lobbying for an export of that function in ghc, and then it would be only compilable with the latest ghc in any case.

A question comes to mind, though: doesn't cabal have the same problem? How does it do it? Is there a way to use a more high level exported function from the ghc library, letting it doing the work?

from argon.

That's an interesting point, I'll check the Cabal source to see if I can find something.

EDIT: Cabal does not seem to use the GHC API. They define their own type to represetn an extension:
https://github.com/haskell/cabal/blob/master/Cabal/Language/Haskell/Extension.hs#L96
which, incidentally, is what Argon uses when the Cabal file is parsed.
However, I just found that the DynFlag module exports some functions which might be of help:
https://www.stackage.org/haddock/lts-6.3/ghc-7.10.3/DynFlags.html#g:5
I haven't checked them all, but at a first glance they seem relevant. Still, creating an ad-hoc command line would be pretty ugly.

from argon.

Which functions in particular could be of help in the dynflags module? Are the correct extensions invoked in, e.g., parseDynamicFlagsCmdLine?

from argon.

Yes, I belive parseDynamicFlagsCmdLine could work. It's just a wrapper

parseDynamicFlagsCmdLine = parseDynamicFlagsFull flagsAll True

but flagsAll contains the flags related to the extensions as well. I just have to test it.

from argon.

Hooray! I finally got around to trying it and I confirm that using parseDynamicFlagsCmdLine works! It's a pretty ugly hack though, there has to be a better solution...

Can you try it?

from argon.

It seems that the modification works; in the end, I invoke the program on hint (and I get no errors) with:

argon --cabal-macros $(stack path --dist-dir)/build/autogen/cabal_macros.h --cabal-file hint.cabal src

I saw the commit, it doesn't seem too bad. Why do you feel it's pretty ugly? The better solution would probably be the export of the setExtensionFlag' function, right? If that's indeed the case, I checked with the folks in the #ghc channel and they proposed me to attach the proposed patch to a trac ticket for ghc.

I put that on hold since you were testing parseDynamicFlagCommandLine, but do you feel that that modification would be still useful/lead to better code?

from argon.

Well I find that the current solution has both some advantages and disadvantages. The main advantage I see is that since we're building a command line, the behaviour will always be the same as the GHC binary.

Still, I don't think it's the right way to proceed. Compare the current solution:

(dflags1,_,_) <- GHC.parseDynamicFlagsCmdLine dflags0
    [GHC.L GHC.noSrcSpan ("-X" ++ e) | e <- exts conf]

with

let dflags1 = foldr setExtensionFlag' dflags0 $ exts conf  -- not tested, but you get the point

In the first case we're doing useless work that will be undone by GHC. Instead, if setExtensionFlag' becomes part of the public API, it will be pretty much guaranteed that it will not break randomly at some point. Moreover, I just don't see why setGeneralFlag' is exported and setExtensionFlag' is not.

Finally, if setExtensionFlag' is exported, there will always be the problem of previous GHC releases, as you've noted. We cannot do anything about this, and probably would have to resort to conditional compilation (Yay!).

What do you think?

from argon.

The right thing to do is exporting setExtensionFlag' in ghc. Our long game would be introducing it when we don't need to support the old versions anymore (a very long game).

I'll try to write a patch later. For now, I have other questions on the code, but I'll open a new issue :)

from argon.