Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious error when loading package into ghci #449

Closed
dalejordan opened this issue Jun 30, 2015 · 7 comments
Closed

Spurious error when loading package into ghci #449

dalejordan opened this issue Jun 30, 2015 · 7 comments
Assignees

Comments

@dalejordan
Copy link

I have a package which builds without error but fails to load in
ghci with a spurious parse error:

[Matrix] $ stack ghci Matrix
Configuring GHCi with the following packages: Matrix
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
[1 of 2] Compiling MatrixInternal   ( /home/dale/stack/Matrix/MatrixInternal.hs, interpreted )
[2 of 2] Compiling Matrix           ( /home/dale/stack/Matrix/Matrix.hs, interpreted )

/home/dale/stack/Matrix/Matrix.hs:114:1:
    Parse error in pattern: (M (_) m v)     --NB. the inner "(_)" is "_" in the source file
Failed, modules loaded: MatrixInternal.
𝛌> :q

The code it is complaining about is:

(!) :: Matrix a -> (Int,Int) -> a
{-# INLINE (!) #-}
(M _ m v) ! ij = v V.! encode m ij

If I specify the major source file it just gives me the ghci prompt,
but I can load the load the modules OK.

[Matrix] $ stack ghci Matrix.hs
Configuring GHCi with the following packages: 
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
𝛌> :t shape

<interactive>:1:1: Not in scope: ‘shape’
𝛌> :l Matrix.hs
[1 of 2] Compiling MatrixInternal   ( MatrixInternal.hs, interpreted )
[2 of 2] Compiling Matrix           ( Matrix.hs, interpreted )
Ok, modules loaded: Matrix, MatrixInternal.
𝛌> :t shape
shape :: Matrix a -> (Int, Int)
𝛌> :q
Leaving GHCi.


[Matrix] $ stack --version
Version 0.1.1.0, Git revision 91fe70306f51eb3d68667a0d6e09a7d7ebbeb2b6

I suppose the latter behaviour is a feature of the stack environment,
but the parse error is mystifying.

@snoyberg
Copy link
Contributor

snoyberg commented Jul 2, 2015

@chrisdone any thoughts?

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jul 2, 2015
@chrisdone
Copy link
Member

Haven't the foggiest what would cause that. I guess you could paste your stack ghci Matrix -v output? https://gist.github.com/

@dalejordan
Copy link
Author

@snoyberg snoyberg modified the milestones: GHCi, 0.2.0.0 Jul 13, 2015
@hesselink
Copy link
Contributor

I've seen this before. It happens because stack ghci enables all extensions from the cabal file. In this case the culprit is BangPatterns (see the GHC documentation on this), which will cause the code to fail to parse.

I think in this case stack shouldn't add the extensions, since they're in the other-extensions field:

For packages using 'cabal-version: >= 1.10' the 'extensions' field is
deprecated. The new 'default-extensions' field lists extensions that are used
in all modules in the component, while the 'other-extensions' field lists
extensions that are used in some modules, e.g. via the {-# LANGUAGE #-}
pragma.

@chrisdone
Copy link
Member

@hesselink Thanks for contributing that tidbit. From the Cabal API documentation there isn't explanation as to how the two fields differ. In other words, the other-extensions field is ignorable for our purposes.

@dalejordan
Copy link
Author

@hesselink : Thanks for pointing out that syntax ambiguity with (!). I changed my code and all is good. I might want to use BangPatterns in that module in the future.

@int-index
Copy link
Contributor

I've run into a more subtle manifestation of this issue because I have PolyKinds in my other-extensions field, so it caused strange type errors that looked like compiler bugs.

I don't think, however, that stack should ignore the other-extensions field. It should enforce it: if the field is present in the .cabal file then only the listed language extensions should be allowed.

But as a short-term workaround, ignoring other-extensions sounds appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants