- Glasgow-haskell-users

GADTs and pattern matching
by Francesco Mazzoli 19 Jun '13

19 Jun '13

Hi list, I had asked this on haskell-cafe but this looks particularly fishy, so posting here in case it is an issue: {-# LANGUAGE GADTs #-} data Foo v where Foo :: forall v. Foo (Maybe v) -- Works foo1 :: Foo a -> a -> Int foo1 Foo Nothing = undefined foo1 Foo (Just x) = undefined -- This works foo2 :: a -> Foo a -> Int foo2 x Foo = foo2' x foo2' :: Maybe a -> Int foo2' Nothing = undefined foo2' (Just x) = undefined -- This doesn't! foo3 :: a -> Foo a -> Int foo3 Nothing Foo = undefined foo3 (Just x) Foo = undefined So it looks like constraints in pattern matching only propagate forwards. Is this intended? Thanks, Francesco

1 1

ConstraintKinds feature suggestion and question about type family peculiarity
by Merijn Verstraaten 17 Jun '13

17 Jun '13

Hello fellow haskellers! I was experimenting with restricting functions operating on GADTs with phantom types to only work on a subset of the possible phantom types. I ended up with the following code: {-# LANGUAGE ConstraintKinds, DataKinds, GADTs, TypeFamilies, TypeOperators #-} import GHC.Prim (Constraint) data Foo a where Foo :: Foo Int Bar :: Foo Char Baz :: Foo Bool type family Restrict a (as :: [*]) :: Constraint type instance where Restrict a (a ': as) = () Restrict x (a ': as) = Restrict x as foo :: Restrict a '[Char, Bool] => Foo a -> Bool foo Bar = True foo Baz = False This seems to works marvellously, but in writing it I ran into 2 annoyances. 1) The type errors produced by trying to use a function on a disallowed phantom type are rather unclear. "Could not deduce (Restrict Int ('[] *)) arising from a use of ‛foo" Which got me thinking, it would be really nice to have a vacuous Constraint that takes an error string as argument, i.e. a constraint that never holds and returns it's error string as type error. This would let you produce far nicer type errors when (ab)using ConstraintKinds and TypeFamilies by, for example, adding an extra Restrict instance "Restrict x '[] = Vacuous "Applying restricted function to disallowed type"" (or something to that effect), producing that message as error rather than the "Could not deduce (Restrict Int ('[] *)" which is a rather unhelpful error if you're not the person that wrote this code and are just using a function with such a Restrict constraint. 2) for some reason the type families syntax always requires a full argument list, which I find rather ugly. I would much prefer to use KindSignatures and write "type family Restrict :: * -> [*] -> Constraint", but GHC does not allow this. Is there a specific reason for not allowing this syntax? Cheers, Merijn Verstraaten

3 2

Cross-compiling GHC: ghc-cabal: /tmp/30869.o: does not exist
by Nikita Karetnikov 14 Jun '13

14 Jun '13

I'm trying to cross-compile GHC 7.6.3; 'make' fails with the mentioned error. How can I debug this issue? I used Guix [1] to build a cross-compiler and related packages: # ./pre-inst-env guix build -K gcc-cross-mips64el-linux-gnu After that I downloaded GHC 7.6.3: # wget http://www.haskell.org/ghc/dist/7.6.3/ghc-7.6.3-src.tar.bz2 Unpacked it: # tar xf ghc-7.6.3-src.tar.bz2 # cd ghc-7.6.3/mk # cp build.mk.sample build.mk Uncommented 'BuildFlavour = unreg' and added 'INTEGER_LIBRARY = integer-simple'. # cd .. # export CROSS_LIBRARY_PATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/lib # export CROSS_CPATH=/nix/store/qkzhg178l4b3fpnj7ival0h6c1mfgi0l-glibc-cross-mips64el-linux-gnu-2.17/include:/nix/store/g4ky5zb70y946pfjiq45sa5pv7qdqgha-linux-libre-headers-cross-mips64el-linux-gnu-3.3.8/include # ./configure \ --target=mips64el-linux-gnu \ --with-gcc=/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc \ --with-ld=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld \ --with-nm=/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-nm # make [...] CROSS_COMPILE="mips64el-unknown-linux-gnu-" "inplace/bin/ghc-cabal" configure --with-ghc="/home/GHC/ghc-7.6.3/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/GHC/ghc-7.6.3/inplace/bin/ghc-pkg" --flag=include-ghc-prim --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --with-gcc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --configure-option=--with-cc="/nix/store/lv3vxm43mmk7f5gc1myzs0aj8pi4a4g7-gcc-cross-mips64el-linux-gnu-4.7.3/bin/mips64el-linux-gnu-gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-install libraries/ghc-prim Configuring ghc-prim-0.3.0.0... ghc-cabal: /tmp/30869.o: does not exist make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 Then I found this bug report [2] and decided to apply the mentioned patch: # cd .. # git clone https://github.com/ghc/ghc.git ghc-github # cd ghc-github # git show f77291d60f33fe601dbe0ff94b0192c5cd4ad6b5 > ld.patch # cd ../ghc-7.6.3 # patch -p1 < ../ghc-github/ld.patch patching file rules/build-package-data.mk Hunk #1 succeeded at 64 (offset -11 lines). # make distclean # ./configure [...] # make Then another error appeared: CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/usr/local/bin/ghc" --with-ghc-pkg="/usr/local/bin/ghc-pkg" --package-db=/home/GHC/ghc-7.6.3/libraries/bootstrapping.conf --disable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --constraint "Cabal == 1.16.0" --constraint "hpc == 0.6.0.0" --constraint "binary == 0.5.1.1" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.9.0.0" --with-gcc="/usr/bin/gcc" --with-ld="/nix/store/jys3nw5rg2a4lrihs7qhflxad4bwyry6-binutils-cross-mips64el-linux-gnu-2.23.2/bin/mips64el-linux-gnu-ld" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" -- dist-boot libraries/Cabal/Cabal Configuring Cabal-1.16.0... ghc-cabal: /tmp/27862.o: does not exist make[1]: *** [libraries/Cabal/Cabal/dist-boot/package-data.mk] Error 1 make: *** [all] Error 2 I can't find any similar reports. Am I on the right track? [1] https://gnu.org/software/guix/ [2] http://hackage.haskell.org/trac/ghc/ticket/6086

1 0

Re-entrant TcRnIf
by p.k.f.holzenspies＠utwente.nl 13 Jun '13

13 Jun '13

Dear GHC-ers, The current API *seems* to assume that all different stages of the compiler pipeline are always passed successively (with the exception of the interleaving of the renamer and the type checker for the sake of Template Haskell), in other words, it is assumed all parsing has been done once we start renaming and that when we desugar the AST, we can through out all type checker state. I'm working on an interactive environment (different in many ways from ghci), in which I would like to incrementally parse a statement, rename it and type check it, after which I may chose to wash, rinse and repeat. This is somewhat problematic in the renamer (at least; this is how far I have come), at the very least with regards to the unique source and the provenance of things. What I'm hoping to do is to generalize the monads in the GHC API to some class, along these lines: class Generalizes m n where glift :: n a -> m a class (GhcMonad m, Generalizes m TcRnIf, Generalizes m CoreM, ...) => GHCAPI m What such a monad needs is to be able to evaluate some function in (for example) the renamer monad, extract the part of the renamer state that needs to persist and store that for whenever another renamer function is evaluated. One such thing would be the supply of unique names. I tried simply carrying over everything in the Env, except the env_top (HscEnv), but this broke things. Upon inspection of the TcGblEnv and TcLclEnv, this seems logical, considering they are dependent on the HscEnv (at least in terms of tcg_type_env_var, but there may be other dependencies I've not spotted). The thing that seems to bite me is the assumption that the top-level environment is assumed to be fixed [1]. In my scenario, this assumption does not hold. Concretely: 1) Do ways exist to carry over the part of the TcRnMonad state that is required to restart the renamer / type checker / etc later on? 2) If not, what parts of the Env, TcGblEnv and TcLclEnv should I copy over to the new state, assuming the HscEnv changed between consecutive runs? 3) Is there a particular reason why the front-end (of the front-end) is defined in an overloaded monad (GhcMonad) and the later bits all take concrete monads (TcRnIf etc.)? Regards, Philip [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/TcRnMonad

2 2

Dona Eus�bia - Lista dos aprovados divulgada
by David Anderson 05 Jun '13

05 Jun '13

Dona Eusébia ANA CLARA DE MORAES HOLANDA, LORENNA DOS SANTOS SILVA, FRANCISCO JEFERSON GUERRA DA COSTA, PEDRO AMARANTE SILVA FILHO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL AGUIAR DE SOUSA, MARIA ISABELA DE BRITO MORAIS, JARDEL SOUSA DA SILVA. SILVANA FERREIRA DE ARAÚJO, ARTHUR MAURICIO DE SOUZA RODRIGUES, LUCAS RAMOS DE LIMA, GLEYCIANNE M. DE CARVALHO, REBECCA ERONIDES NOJOSA ARRUDA. Caiapônia. Amontada AMANDA AZEVEDO DE CASTRO FROTA ARAGAO, LEONARDO ARAUJO DE SOUSA, FRANCISCA NAGIELE SILVA, PABLO RICHEL SOARES MENDES, JOÃO CARLOS MOREIRA DE CARVALHO, CLOVIS JOSE PINHEIRO PADILHA, MARIA DE LOURDES CORDEIRO, IZAEL DIAS DA SILVA. SANDRO NEVES DE SILVA, EMYLIA KAROLINE ARARUNA MACEDO, MAYALLE DE LIMA, JOSELÂNE DOS SANTOS FERREIRA, WANDERLEIYA CICERA SIQUEIRA. Cláudia. Antônio Prado de Minas ANA CLARA DE MORAES HOLANDA, LORENNA DOS SANTOS SILVA, FRANCISCO JEFERSON GUERRA DA COSTA, PEDRO AMARANTE SILVA FILHO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL AGUIAR DE SOUSA, MARIA ISABELA DE BRITO MORAIS, JARDEL SOUSA DA SILVA. SILVANA FERREIRA DE ARAÚJO, ARTHUR MAURICIO DE SOUZA RODRIGUES, LUCAS RAMOS DE LIMA, GLEYCIANNE M. DE CARVALHO, REBECCA ERONIDES NOJOSA ARRUDA. Cláudia.

1 0

dialog box error during compile
by harry 02 Jun '13

02 Jun '13

(I posted the following to gmane.comp.lang.haskell.glasgow.bugs, but I think that might have been the wrong list.) I was recently having some trouble building a package through an IDE. When I tried it from the command line, GHC popped up the following dialogue box: ghc.exe - Entry Point Not Found The procedure entry point deflateSetHeader could not be located in the dynamic link library zlib1.dll. I fixed the error, but I hadn't seen it earlier because the IDE (EclpiseFP) only gave GHC a console, where the error wasn't written. Why wasn't it written to the error stream like any other error? Haskell Platform 2013.2 on Windows. The error occurred when building an application that uses gtk2hs.

1 0

Debugging GHCi
by Mateusz Kowalczyk 01 Jun '13

01 Jun '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Nowadays I'm looking at Haddock and amongst other things, recent GHC is a must. Due to this, I now have 7.6.3 on my system as well as a build from yesterday (7.7.20130531), straight from git HEAD. Building Haddock with --enable-tests, I then try to run some hspec (or probably more appropriately, nanospec) tests. Simple stuff: > ghci src/Spec.hs > Prelude> :main Tests run as expected and everything is fine until about 2 seconds after main terminates: GHCi segfaults. As a means of checking whether this is a problem with GHCi, I ran the same commands with my 7.6.3 install and everything was fine - no segfault. This clearly points to something being wrong with GHCi. My question is, how would I even begin to investigate what's wrong? If I want to file a bug, I need to have more information, especially considering that someone I asked could not reproduce this. I have no experience with GHCis guts and I'm not sure how to progress. - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRqnINAAoJEM1mucMq2pqXSbEQAIM9+czAgoyHJQ4LCI+eRMWP yM6pCxvQH5XLfSg6dD9UJASqsZ3kgaQcJsx77c1PCDXyU11hF5x3MygKOBKcqXoO fC/khWqp1ru17tOhJ9nfpCTFm6HUI9RGKRYBJhsrUkv1DzY6tw5kJuwFqf/9e9jF Om9wiqA1Sp0L1YEGnjcQ+ZB2/5gekPK4Il1iSWujrvo9JzGzJULXo94sxAXNa9P+ xuaSpTxKP1+6+zmuK1sSYgNNCP8b5yKXgwUjjI25s8MP6usXpvz5YRs760zMlpFl l9ZepNMiWgcL9dxWI3g8TFrm3jE5EVgIQ+/3ytEoRuetYU713Dj4DQSu5dZkxZku wdWuy/HVBOqpQf+fbMqlH4vW4Q4QIJbnU+qsRr6nNyoyEvGvuom4gXC18fHYqJST r03WD/UXlF4KTXD45flypeOnkRrcFiws76gdRqwiXpec0WxmYjEYGzbIARfQrU9V xWoykrTmVCbE8uG8FktXcjzirSAK5HAsy0sceurgPT8FDmSn9AFF03pOiW/A8Hli d8WrS5uuTWprzFFaUtpPbERWLOxieLNJrpXeeKKICVLF4VNzlrjw9regToYh2rTq tMaJgP61E8Vji2NhR1bk/TPPdOFtEB+cJnXDrn9Z6ICJlAmHXVCCQJA7KmsX5WGA NEqif1T5kIkHLc0FUmZl =nTqG -----END PGP SIGNATURE-----

1 0

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