- Glasgow-haskell-users

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 02 Jun '13

02 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

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