- ghc-devs - Haskell.org

Re: [commit: packages/base] ghc-7.8: Update changelog.md (d762c0c)
by Gabor Greif 11 Jul '14

11 Jul '14

See this comment on Reddit: http://www.reddit.com/r/haskell/comments/2af4jf/ghc783_is_out/ciufcfc Gabor On 7/11/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : ghc-7.8 > Link : > http://ghc.haskell.org/trac/ghc/changeset/d762c0c11b3e9b3031c76caaa895202d1… > >>--------------------------------------------------------------- > > commit d762c0c11b3e9b3031c76caaa895202d1b81acdf > Author: Herbert Valerio Riedel <hvr(a)gnu.org> > Date: Fri Jul 11 13:58:41 2014 +0200 > > Update changelog.md > > >>--------------------------------------------------------------- > > d762c0c11b3e9b3031c76caaa895202d1b81acdf > changelog.md | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/changelog.md b/changelog.md > index 5eef01f..bb42c1e 100644 > --- a/changelog.md > +++ b/changelog.md > @@ -1,6 +1,6 @@ > # Changelog for [`base` package](http://hackage.haskell.org/package/base) > > -## 4.7.0.1 *Jun 2014* > +## 4.7.0.1 *Jul 2014* > > * Bundled with GHC 7.8.3 > > @@ -11,6 +11,8 @@ > > * Fix regression in Data.Fixed Read instance (#9231) > > + * Fix `fdReady` to honor `FD_SETSIZE` (#9168) > + > ## 4.7.0.0 *Mar 2014* > > * Bundled with GHC 7.8.1 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Explicitly bidirectional pattern synonyms for 7.8.3?
by Dr. ERDI Gergo 11 Jul '14

11 Jul '14

Hi, I've spent the last couple evenings implementing explicitly-bidirectional pattern synonyms, partly while waiting for someone to help out with #9023. Explicitly-bidirectional pattern synonyms are described in #8581. My question is: now that I have this mostly working, is this something that could be added to 7.8.3, or is this too much of a new feature for a point release? I'd like to know because then I can prioritize finishing the work (it still needs some tests added and also someone to review the changes). Thanks, Gergo

3 3

Injective type families
by Jan Stolarek 11 Jul '14

11 Jul '14

Hi all, I'd like to take a stab at implementing injective type families (#6018). My plan of attack looks like this: 1. Implement injective type families that are: a) injective in all arguments b) only admit RHS that is a concrete type or a type variable introduced by the LHS or a recursive call to self. 2. Lift restriction a) ie. allow type families injective only in some arguments 3. Lift restriction b) ie. allow injective type families to call other type families. I'm not sure if 3) really gets implemented as this seems more in lines of #4259, which I don't intend to approach. Now, let's discuss the most important of all matters - the syntax! :-) Note that syntax must: 1. allow to define injectivity only for some parameters 2. work for both open and closed type families Here's my proposal (based on Richard's idea to use functional-dependencies-like syntax): 1. Standard injective type family (all parameters uniquely determined by the RHS): injective type family F a b c | a b c type family instance F Int Char Bool = Bool type family instance F Char Bool Int = Int type family instance F Bool Int Char = Char 2. Type family injective only in some parameters (ie. only some parameters uniquely determined by the RHS): injective type family G a b c | a b type family instance G Int Char Bool = Bool type family instance G Int Char Int = Bool type family instance G Bool Int Int = Int Here knowing the RHS allows us to determine a and b, but not c. 3. Type families where knowing the RHS and some parameters on the LHS makes other parameters injective: Example 1: knowing the RHS and any single parameter uniquely determines other parameters injective type family H a b c | a -> b c, b -> a c, c -> a b type family instance H Int Char Double = Int type family instance H Bool Double Char = Int Example 2: knowing the RHS and either a or b allows to uniquely determine other parameters, but knowing the RHS and c gives us no information about a or b injective type family J a b c | a -> b c, b -> a c type family instance J Int Char Double = Int type family instance J Bool Double Double = Int For closed type families this notation would be identical: type family declaration would be followed by the "where" keyword. In comment 34 of #6018 Richard proposed a notation that uses a keyword "Result". This would allow for a more uniform notation. Notice that in my proposal some families use ->, while others don't. The idea is that on the right side of the arrow we write what we can infer from the things on the left of the arrow. If the only thing left of the arrow is the right hand side of the type family equation (the result) then the arrow can be elided. In other words these would be equivalent: injective type family F a b c | a b c injective type family F a b c | result -> a b c injective type family G a b c | a b injective type family G a b c | result -> a b (note: it is also true that "injective type family G a b c | result c -> a b") injective type family H a b c | a -> b c, b -> a c, c -> a b injective type family H a b c | result a -> b c, result b -> a c, result c -> a b injective type family J a b c | a -> b c, b -> a c injective type family J a b c | result a -> b c, result b -> a c I find the notation explicitly using "result" to be easier to understand, but it is also more verbose. I also suspect that it might be a bit easier to parse. Which of the notations do you find better? What do you think about using the "injective" keyword? Are there any alternative proposals? Janek

6 7

GHC silently turns off dynamic output, should this be an error?
by Christopher Rodrigues 08 Jul '14

08 Jul '14

Hello, I’ve investigated an issue (#9176) where ghc with --make -dynamic-too appears to run successfully but doesn’t generate some .dyn_hi files. The cause seems to be that GHC silently turns off dynamic-too output when it finds an inconsistency between the .hi and .dyn_hi interface hashes of an imported module. The symptom, for me, is that some cabal packages will build but fail to install. The real problem is most likely not in the failing package, but in an imported module from a package that’s already installed. I’m inclined to say that GHC should stop with an error in this situation, which would produce a visible error when the file fails to compile. However, since GHC carefully avoids bailing out, I wonder if I’m missing something. Is there a good reason to turn off dynamic-too output instead of reporting an error? Additionally, is it ever valid to have a pair of .hi and .dyn_hi files with different interface hashes? Or is it invalid data, in the same way that a corrupted .hi file is invalid data? I’m inclined to say that it is invalid data, because -dynamic-too promises to generate two different (static and dynamic) implementations of the same Haskell code, taking two different implementations of the same imported Haskell modules as input. If the inputs aren’t really two different implementations of the same Haskell code, you’ve somehow provided invalid input.

5 5

Continuous Integration and Cross Compilation
by William Knop 08 Jul '14

08 Jul '14

Hello all, I’ve seen quite a few comments on the list and elsewhere lamenting the time it takes to compile and validate ghc. It’s troublesome not only because it’s inconvenient, but, more seriously, people are holding off on sending patches in which stifles development. I would like to propose a solution: 1. Implement proper cross-compilation, such that build and host may be different— e.g. a linux x86_64 machine can build ghc that runs on Windows x86. What sort of work would this entail? 2. Batch cross-compiled builds for all OSs/archs on a continuous integration service (e.g. Travis CI) or cloud service, then package up the binaries with the test suite. 3. Send the package to our buildbots, and run the test suite. 4. (optional) If using a CI service, have the buildbots send results back to the CI. This could be useful if we'd use GitHub for pulls in the future *. Cheers, Will * I realize vanilla GitHub currently has certain annoying limitations, though some of them are pretty easy to solve via the github-services and/or webhooks. I don’t think this conflicts with the desire to use Phabricator, either, so I’ll send details and motivations to that thread.

7 12

Re: GHC status report
by Miëtek Bak 07 Jul '14

07 Jul '14

On 2014-05-01, at 23:46, Edward Kmett <ekmett(a)gmail.com> wrote: > With the old custom linker we weren't able to get our custom MPFR linked in > properly on all platforms for use in ghci. > > On Macs we ran into some rather interesting problems. We could get it to > work for actual executables, but ghci would segfault with stuff resolved to > clearly wrong addresses. If I recall correctly it may have been some kind > of MachO symbol type that wasn't being resolved properly by the custom GHC > linker, perhaps? We chased after it off and on for a long time to no avail. Did these segfaults look like the following GHCi 7.6.3 crash? https://ghc.haskell.org/trac/ghc/ticket/9278 It looks like Jason ran into something similar last year: https://gist.github.com/dagit/5986541 Unfortunately, while the new linker in GHCi 7.8.2 doesn’t suffer from this problem, there appears to be another issue: https://ghc.haskell.org/trac/ghc/ticket/9277 Any clues? Thanks, -- Miëtek

1 0

Re: GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 05 Jul '14

05 Jul '14

How would you do reification with that approach? On Sat, Jul 5, 2014 at 9:59 PM, John Meacham <john(a)repetae.net> wrote: > Actually, I was looking into it a little, and template haskell could > effectively be implemented by a pre-processor and a portable library > that is compiler independent. If one could get ghc to spit out the > template haskell source after it expands it then that can be fed to > jhc as a quick first pass, but ideally the pre-processor TH would > create programs that can be run under the target compiler. that would > bring TH to every haskell compiler. > > John > > On Sat, Jul 5, 2014 at 10:38 AM, Brandon Allbery <allbery.b(a)gmail.com> > wrote: > > On Sat, Jul 5, 2014 at 1:34 PM, Carter Schonwald > > <carter.schonwald(a)gmail.com> wrote: > >> > >> does JHC support template haskell? > > > > > > Pretty sure TH is too closely tied to ghc. > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > -- > John Meacham - http://notanumber.net/ > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >

2 2

"No entry for "Haskell CPP command"" error with testsuite
by Jan Stolarek 05 Jul '14

05 Jul '14

I'm trying to run the testsuite in my symlinked build tree, but keep getting this error: [killy@xerxes : /dane/projekty/ghc/build] make test make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: Wejście do katalogu `/dane/projekty/ghc/build/testsuite/tests' ../mk/boilerplate.mk:168: ../mk/ghcconfig_dane_projekty_ghc_build_inplace_bin_ghc-stage2.mk: No such file or directory "/dane/projekty/ghc/build/inplace/bin/ghc-stage2" --make -o ../mk/ghc-config ../mk/ghc-config.hs No entry for "Haskell CPP command" in "/dane/projekty/ghc/build/inplace/lib/settings" make[1]: *** [../mk/ghc-config] Error 1 make[1]: Leaving directory `/dane/projekty/ghc/build/testsuite/tests' make: *** [test] Error 2 Help? Janek

5 6

GHCJS now runs Template Haskell on node.js - Any interest in out of process TH for general cross compilation?
by Luite Stegeman 04 Jul '14

04 Jul '14

hi all, I've added some code [1] [2] to GHCJS to make it run Template Haskell code on node.js, rather than using the GHC linker. GHCJS has supported TH for a long time now, but so far always relied on native (host) code for it. This is the main reason that GHCJS always builds native and JavaScript code for everything (another is that Cabal Setup.hs scripts need to be compiled to some host-runnable form, but that can also be JavaScript if you have node.js) Now besides the compiler having to do twice the work, this has some other disadvantages: - Our JavaScript code has the same dependencies (packages) as native code, which means packages like unix or Win32 show up somewhere, depending on the host environment. This also limits our options in choosing JS-specific packages. - The Template Haskell code runs on the host environment, which might be slightly different from the target, for example in integer size or operating system specific constants. Moreover, building native code made the GHCJS installation procedure more tricky, making end users think about libgmp or libiconv locations, since it basically required the same preparation as building GHC from source. This change will make installing much easier and more reliable (we still have to update the build scripts). How it works is pretty simple: - When any code needs to be run on the target (hscCompileCoreExpr, through the Hooks API new in GHC 7.8), GHCJS starts a node.js process with the thrunner.js [3] script, - GHCJS sends its RTS and the Template Haskell server code [1] to node.js, the script starts a Haskell thread running the server, - for every splice, GHCJS compiles it to JavaScript and links it using its incremental linking functionality. The code for the splice, including dependencies that have not yet been sent to the runner (for earlier splices), is then sent in a RunTH [4] message, - the runner loads and runs the code in the Q monad, can send queries to GHCJS for reification, - the runner sends back the result as a serialized Template Haskell AST (using GHC.Generics for the Binary instances). All Template Haskell functionality is supported, including recent additions for reifying modules and annotations. I still need to clean up and push the patches for the directory and process packages, but after that, the TH code can read/write files, run processes and interact with them and make network connections, all through node.js. Now since this approach is in no way specific to JavaScript, I was wondering if there's any interest in getting this functionality into GHC 7.10 for general cross compilation. The runner would be a native (target) program with dynamic libraries (or object files) being sent over to the target machine (or emulator) for the splices. Thanks to Andras Slemmer from Prezi who helped build the initial proof of concept (without reification) at BudHac. cheers, Luite [1] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [2] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812… [3] https://github.com/ghcjs/ghcjs/blob/414eefb2bb8825b3c4c5cddfec4d79a142bc261… [4] https://github.com/ghcjs/ghcjs-prim/blob/2dffdc2d732b044377037e1d6ebeac2812…

6 9

Holiday
by Simon Peyton Jones 04 Jul '14

04 Jul '14

Friends I'm on holiday all next week, back 14 July. I'm not taking my laptop! Simon

1 0