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

@dalejordan dalejordan commented Jun 30, 2015

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 snoyberg commented Jul 2, 2015

@chrisdone any thoughts?

Loading

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

@chrisdone chrisdone commented Jul 3, 2015

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

Loading

@dalejordan
Copy link
Author

@dalejordan dalejordan commented Jul 3, 2015

Loading

@snoyberg snoyberg added this to the GHCi milestone Jul 13, 2015
@snoyberg snoyberg removed this from the 0.2.0.0 milestone Jul 13, 2015
@hesselink
Copy link
Contributor

@hesselink hesselink commented Jul 14, 2015

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.

Loading

@chrisdone
Copy link
Member

@chrisdone chrisdone commented Jul 14, 2015

@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.

Loading

@dalejordan
Copy link
Author

@dalejordan dalejordan commented Jul 14, 2015

@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.

Loading

@int-index
Copy link
Contributor

@int-index int-index commented Jul 18, 2015

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.

Loading

@chrisdone chrisdone closed this in 30acfc4 Jul 18, 2015
@borsboom borsboom removed this from the GHCi milestone Sep 12, 2015
@borsboom borsboom removed this from the GHCi milestone Sep 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants