foreign is a keyword in latest GHC

[reactormonk]

Just tried compiling it with 8.6 - failed because foreign is now a keyword by default.

[evancz]

I am working with GHC 8.6.3 and not having troubles with this.

What specific version of GHC are you using?

[jhrcek]

I don't know about @reactormonk but I also run into this issue when doing some just-for-fun explorations of the compiler source code. Using GHC 8.6.5, ending up doing similar fix: jhrcek@60a1fa5
It's actually possible to compile the code using GHC, but I was getting an error loading the code into GHCi:

/home/jhrcek/Devel/github.com/jhrcek/compiler/compiler/src/Parse/Variable.hs:152:10: error:
    parse error on input ‘foreign’
    |
152 |         !foreign =
    |          ^^^^^^^
Failed, 24 modules loaded.

It seems to be this GHCi specific issue.

[evancz]

There is limited bandwidth for making it build with all the various versions of GHC and various packages that are coming out, as described here.

I think it makes sense to just focus on making the code compile for the official release process. The goal of the release process is to produce well-tested binaries for various platforms that come out with specific releases, like 0.19.0 or 0.19.1. From that perspective, it only needs to build with a particular GHC and a particular set of dependencies.

[jhrcek]

@evancz This particular change (renaming one variable in 2 places) has high power-to-weight ratio, making the code compatible with more versions of GHC almost for free. Despite closing this PR, could you please still reconsider doing the change?

[turboMaCk]

While I agree with keeping the focus on producing official binaries one should not forget that there are pretty valid reasons why supporting from source compilation is also important. For instance, cross-compilation to ARM, FreeBSD support and probably many more. Even though this specific case seems like a bug in GHCi and not a compatibility issue with newer GHC it would be nice to see from source compilation as at least the 2nd class citizen so the community can provide support for the last 10% of cases where official binaries can't.

[evancz]

Here are the facts in the thread:

1. We have no confirmation of compilation failing with a GHC 8.6.* version.
2. We do have one person saying it fails to load in ghci with a specific report on GHCi about how that is a bug in GHCi.
3. Loading the compiler in ghci is not necessary to build on the platforms mentioned by @turboMaCk.

Seems like the root problem here is in GHCi, and folks building from source will be in the same situation as always. I.e. it is hard to build projects in the Haskell ecosystem due to the 6-month release cycle and loose constraints on almost all packages.

[reactormonk]

I'm running 8.6.5 over here, via lts-13.30. It fails via stack build, not ghci.

[monoidal]

In Haskell 2010, foreign is a keyword. The code should not compile unless you use -XHaskell98 or -XNoForeignFunctionInterface. This shouldn't be a matter of specific GHC version or ghci.

The linked ghci bug does not apply here: it was fixed in 7.10, and it concerns using foreign as a variable name inside the REPL, not when loading a module.

I recommend accepting the patch: it's really small and Haskell 2010 is the current standard of the language. This is not something that changes often.

[evancz]

The facts still do not add up given that this works fine in GHC 8.6.3 and 8.4.3 for me and we still do not have a confirmed reproduction, but I switched it in 2860c2e so this thread can be over.

In the future, please include (1) the specific version you are using so that the problem can be reproduced and confirmed to exist and (2) supporting evidence (links, code, etc.) for any claims about what is and is not expected behavior in various Haskell versions.