May 2013 - Glasgow-haskell-users

match_co: needs more cases
by Evan Laforge 07 Nov '13

07 Nov '13

I made some strictifying changes and started getting this msg from ghc: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc r46} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc r45})>) <main:Util.TimeVectorStorable.Sample{tc r4e} y{tv a4lK} [tv]> It's not just TimeVectorStorable.Sample (which is indeed stored in Data.Vectors), we also have some mysterious compiler-generated symbols: match_co: needs more cases vector-0.10.0.1:Data.Vector.Generic.Mutable.MVector{tc rQA} (Sym <(vector-0.10.0.1:Data.Vector.TFCo:R:MutableVector{tc rQz})>) <a{tv a6IH} [tv]> I assume this is harmless, but I didn't see any other references to this error on the web or on the ghc trac so maybe it's new?

4 5

Repeated variables in type family instances
by Richard Eisenberg 26 Jun '13

26 Jun '13

(Sorry for the re-send - got the wrong subject line last time.) Hello all, It's come to my attention that there is a tiny lurking potential hole in GHC's type safety around type families in the presence of UndecidableInstances. Consider the following: > type family F a b > type instance F x x = Int > type instance F [x] x = Bool > > type family G > type family G = [G] This declarations are all valid in GHC 7.6.3. However, depending on the reduction strategy used, it is possible to reduce `F G G` to either Int or Bool. I haven't been able to get this problem to cause a seg-fault in practice, but I think that's more due to type families' strictness than anything more fundamental. Thus, we need to do something about it. I have written a proposal on the GHC wiki at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity It proposes a change to the syntax for branched instances (a new form of type family instance that allows for ordered matching), but as those haven't yet been officially released (only available in HEAD), I'm not too worried about it. There are two changes, though, that break code that compiles in released versions of GHC: --- 1) Type family instances like the two for F, above, would no longer be accepted. In particular, the overlap check for unbranched (regular standalone instances like we've had for years) would now check for overlap if all variables were distinct. (This freshening of variables is called 'linearization'.) Thus, the check for F would look at `F x y` and `F [x] y`, which clearly overlap and would be conflicting. 2) Coincident overlap between unbranched instances would now be prohibited. In the new version of GHC, these uses of coincident overlap would have to be grouped in a branched instance. This would mean that all equations that participate in coincident overlap would have be defined in the same module. Cross-module uses of coincident overlap may be hard to refactor. --- Breaking change #1 is quite necessary, as that's the part that closes the hole in the type system. Breaking change #2 is strongly encouraged by the fix to #1, as the right-hand side of an instance is ill-defined after the left-hand side is linearized. It is conceivable that there is some way to recover coincident overlap on unbranched instances, but it's not obvious at the moment. Note that this proposal does not contain a migration path surrounding coincident overlap. In GHC <= 7.6.x, branched instances don't exist and we have coincident overlap among unbranched instances; and in GHC >= 7.8.x, we will prohibit coincident overlap except within branched instances. We (Simon PJ and I) think that this shouldn't be too big of a problem, but please do shout if it would affect you. Please let me know what you think about this proposal! Thanks, Richard

3 10

RE: Module import and use in GHC plugin?
by Simon Peyton-Jones 30 May '13

30 May '13

Plugin support is not well documented, and could do with some love. If someone would like to take it up, I'm sure it could be improved a lot. Simon From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Amos Robinson Sent: 29 May 2013 23:50 To: Conal Elliott Cc: glasgow-haskell-users(a)haskell.org; ghc-devs(a)haskell.org Subject: Re: Module import and use in GHC plugin? I'd love to know a nicer way to do this, but what Ben Lippmeier did as a workaround is require a binding "repa_primitives = R.primitives" where repa_primitives is a record with references to all the primitive types you need. It's not great, but it works. Plugin code: http://code.ouroborus.net/repa/repa-head/repa-plugin/Data/Array/Repa/Plugin… Primitives export: http://code.ouroborus.net/repa/repa-head/repa-series/Data/Array/Repa/Series… On Thu, May 30, 2013 at 7:37 AM, Conal Elliott <conal(a)conal.net<mailto:conal@conal.net>> wrote: In writing GHC plugins, how can I (a) add a module import (preferably qualified) and (b) make vars/ids for names imported from the newly imported module (to insert in the transformed Core code)? If it's not possible to do what I want, I'd be willing to require an explicit import (say "import qualified Foo") in client code, as a temporary workaround. So far I've been unable to import even from the base package. Maybe I'm missing something basic that you folks have learned. My simple & unsuccessful attempt is at https://github.com/conal/plugin-import-id . Help greatly appreciated. Thanks, - Conal _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

Module import and use in GHC plugin?
by Conal Elliott 29 May '13

29 May '13

In writing GHC plugins, how can I (a) add a module import (preferably qualified) and (b) make vars/ids for names imported from the newly imported module (to insert in the transformed Core code)? If it's not possible to do what I want, I'd be willing to require an explicit import (say "import qualified Foo") in client code, as a temporary workaround. So far I've been unable to import even from the base package. Maybe I'm missing something basic that you folks have learned. My simple & unsuccessful attempt is at https://github.com/conal/plugin-import-id . Help greatly appreciated. Thanks, - Conal

1 0

Branched type family instances
by Richard Eisenberg 29 May '13

29 May '13

Hello all, It's come to my attention that there is a tiny lurking potential hole in GHC's type safety around type families in the presence of UndecidableInstances. Consider the following: > type family F a b > type instance F x x = Int > type instance F [x] x = Bool > > type family G > type family G = [G] This declarations are all valid in GHC 7.6.3. However, depending on the reduction strategy used, it is possible to reduce `F G G` to either Int or Bool. I haven't been able to get this problem to cause a seg-fault in practice, but I think that's more due to type families' strictness than anything more fundamental. Thus, we need to do something about it. I have written a proposal on the GHC wiki at http://hackage.haskell.org/trac/ghc/wiki/NewAxioms/Nonlinearity It proposes a change to the syntax for branched instances (a new form of type family instance that allows for ordered matching), but as those haven't yet been officially released (only available in HEAD), I'm not too worried about it. There are two changes, though, that break code that compiles in released versions of GHC: --- 1) Type family instances like the two for F, above, would no longer be accepted. In particular, the overlap check for unbranched (regular standalone instances like we've had for years) would now check for overlap if all variables were distinct. (This freshening of variables is called 'linearization'.) Thus, the check for F would look at `F x y` and `F [x] y`, which clearly overlap and would be conflicting. 2) Coincident overlap between unbranched instances would now be prohibited. In the new version of GHC, these uses of coincident overlap would have to be grouped in a branched instance. This would mean that all equations that participate in coincident overlap would have be defined in the same module. Cross-module uses of coincident overlap may be hard to refactor. --- Breaking change #1 is quite necessary, as that's the part that closes the hole in the type system. Breaking change #2 is strongly encouraged by the fix to #1, as the right-hand side of an instance is ill-defined after the left-hand side is linearized. It is conceivable that there is some way to recover coincident overlap on unbranched instances, but it's not obvious at the moment. Note that this proposal does not contain a migration path surrounding coincident overlap. In GHC <= 7.6.x, branched instances don't exist and we have coincident overlap among unbranched instances; and in GHC >= 7.8.x, we will prohibit coincident overlap except within branched instances. We (Simon PJ and I) think that this shouldn't be too big of a problem, but please do shout if it would affect you. Please let me know what you think about this proposal! Thanks, Richard

1 0

A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
by Daniel Gorín 28 May '13

28 May '13

Hi all, Given the ongoing discussion in the libraries mailing list on replacing (or removing) list functions in the Prelude in favor of the Foldable / Traversable generalizations, I was wondering if this wouldn't be better handled by a mild (IMO) extension to the module system. In a nutshell, the idea would be 1) to allow a module to export a specialized version of a symbol (e.g., Prelude could export Foldable.foldr but with the specialized type (a -> b -> b) -> b -> [a] -> b) and 2) provide a disambiguation mechanism by which when a module imports several versions of the same symbol (each, perhaps, specialized), a sufficiently general type is assigned to it. The attractive I see in this approach is that (enabling an extension) one could just import and use Foldable and Traversable (and even Category!) without qualifying nor hiding anything; plus no existing code would break and beginners would still get the friendlier error of the monomorphic functions. I also expect it to be relatively easy to implement. In more detail, the proposal is to add two related language extensions, which, for the sake of having a name, I refer to here as MoreSpecificExports and MoreGeneralImports. 1) With MoreSpecificExports the grammar is extended to allow type annotations on symbols in the export list of a module. One could then have, e.g., something like: {-# LANGUAGE MoreSpecificExports #-} module Data.List ( ... Data.Foldable.foldr :: (a -> b -> b) -> b -> [a] -> b , Data.Foldable.foldl :: (b -> a -> b) -> b -> [a] -> b ... ) where import Data.Foldable ... instance Foldable [] where ... For consistency, symbols defined in the module could also be exported specialized. The type-checker needs to check that the type annotation is in fact a valid specialization of the original type, but this is, I think, straightforward. 2) If a module imports Data.List and Data.Foldable as defined above *without* the counterpart MoreGeneralImports extension, then Data.List.foldr and Data.Foldable.foldr are to be treated as unrelated symbols, so foldr would be an ambiguous symbol, just like it is now. If on the other hand a module enables MoreGeneralImports and a symbol f is imported n times with types T1, T2, ... Tn, the proposal is to assign to f the most general type among T1... Tn, if such type exists (or fail otherwise). So if in the example above we enable MoreGeneralImports, foldr will have type Foldable t => (a -> b -> b) -> b -> t a -> b, as desired. (It could be much more interesting to assign to f the least general generalization of T1...Tn, but this seems to require much more work (unless GHC already implements some anti-unification algorithm); also I'm not sure whether this would interact well with GADTs or similar features and in any case this could be added at a later stage without breaking existing programs). Would something like this address the problem? Are there any interactions that make this approach unsound? Any obvious cons I'm not seeing? Feedback is most welcome! Thanks, Daniel

6 11

Re: porting to uClibc-based 686 Linux
by Dubiousjim 21 May '13

21 May '13

Just to follow-up on my earlier emails about trying to port GHC to a uClibc-based Linux, I finally did get this working, on both x86 and x86_64. There were a bunch of small stumbling blocks and one big one that I finally traced to the fact that the native gcc on my target system had the Gentoo hardening patches, and one needed to supply a "-nopie" option to selectively disable these. (This was counter-intuitive because the error messages made it seem that what was wanted was to *enable* PIE compiling, not to disable it.) I finally identified this issue when reading http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml. Anyway, I've written up what it took to port GHC to our system on our distro's wiki: http://wiki.alpinelinux.org/wiki/Porting_GHC_to_Alpine Perhaps that might help others attempting similar feats, or might help the ghc devs working on the build system to make this less painful in the future. -- dubiousjim(a)gmail.com

1 0

nightly builds: empty directory
by Henning Thielemann 20 May '13

20 May '13

The page http://www.haskell.org/ghc/download refers to directories for the nightly builds, that are actually empty: http://www.haskell.org/ghc/dist/current/dist/ http://www.haskell.org/ghc/dist/stable/dist/ :-(

3 2

A type not inferred with RankNTypes
by Akio Takano 13 May '13

13 May '13

Hi, The attached program does not typecheck if I don't include a type signature for 'bar' (the line C). I can't figure out if this is a limitation in the type system or a bug in GHC. One thing that confuses me is that replacing the line (B) with (A) makes the program typecheck. Could anyone help me figuring out what is going on? I'm using GHC 7.6.2. The error was: % ghc forall.hs [1 of 1] Compiling Foo ( forall.hs, forall.o ) forall.hs:18:11: Could not deduce (Fractional a) arising from the literal `0.1' from the context (Num (Scalar t), Scalar t ~ a) bound by a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t at forall.hs:18:7-13 Possible fix: add (Fractional a) to the context of a type expected by the context: (Num (Scalar t), Scalar t ~ a) => AD t or the inferred type of bar :: a In the first argument of `foo', namely `0.1' In the expression: foo 0.1 In an equation for `bar': bar = foo 0.1 Regards, Takano Akio

3 2

Missing snapshots
by Mateusz Kowalczyk 13 May '13

13 May '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, On the GHC download page [1], there are no available snapshots. Both HEAD and STABLE branch dist directories are empty. Any idea what the deal is? [1] - http://www.haskell.org/ghc/download - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5 eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA 973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/ q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+ +OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyMworGJU89aWkaKG+Bjlf2xWOS mqVoJArrZCv7tkYoLdN2 =rENI -----END PGP SIGNATURE-----

4 3