Stack + GHCJS

[ElvishJerricco]

When running ghc-mod using Stack in a GHCJS project, it fails to find ghc with this error:

> stack exec ghc-mod -- browse Lib
Pattern match failure in do expression at Language/Haskell/GhcMod/Stack.hs:43:3-10

This function just searches for ghc on the path, but it needs to be using stack ghc.

Here's my stack.yaml.

resolver: lts-5.14
compiler: ghcjs-0.2.0.20160414_ghc-7.10.2
compiler-check: match-exact
setup-info:
  ghcjs:
    source:
      ghcjs-0.2.0.20160414_ghc-7.10.2:
        url: https://s3.amazonaws.com/ghcjs/ghcjs-0.2.0.20160414_ghc-7.10.2.tar.gz
        sha1: f0a7243e781e27ebfe601eebaf5c57422007c142


packages:
- '.'

extra-deps: []

flags: {}

extra-package-dbs: []

[DanielG]

This function just searches for ghc on the path, but it needs to be using stack ghc.

Nope it looks on the same paths that stack ghc uses, i.e. what stack path returns under bin-path.

Also ghc-mod doesn't support ghcjs so be careful.

[ElvishJerricco]

Yes, sorry I should have been more clear.

Rather than using stack ghc it's searching for ghc exactly on the stack path. But with GHCJS, stack ghc executes ghcjs, not ghc. So searching for ghc is incorrect, because the compiler might be named something different. Using stack ghc guarantees that you use the project's desired compiler.

[DanielG]

Ah, ok. See the thing is since we don't support ghcjs no such logic is implemented and I don't see any point in adding this unless we actually work with ghcjs at all, right?

Not to mention that the ghc program we're looking for here absolutely should be the host ghc (i.e. one targeting x86 or somesuch) since it's passed down to cabal-helper so it can compile itself. Maybe an argument could be made that in this case we should not use stack path to look for a host ghc or maybe even debate whether or not Stack should provide a host ghc when using a cross compiler like ghcjs just for cases like this (I think it probably ought to).

See #654 for some discussion about implementing ghcjs support.

[ElvishJerricco]

Interesting. I think the "point" would be a novel level of correctness, since, theoretically, stack could always use a compiler not named "ghc", even if it's a host compiler. But this isn't actually a problem (stack currently only ever looks for ghc or ghcjs), and it's not solving the actual problems you mentioned.