July 2014 - ghc-devs - Haskell.org

RE: A couple of GHC-API questions
by Simon Peyton Jones 24 Jul '14

24 Jul '14

Eric I'd like to help but I don't understand the question. What do you mean by "resolve" all the types that are imported from module A? If you have a TyCon (for A.Foo) in your hand, it has a Name. That Name tells you where it comes from. Inside it you will find its DataCons which also come from A. And so on. Later you say "is there a simple way to ask GHC to resolve the name x in the context of module m". You could mean * Imagine that the unqualified name "x" appeared in module m. How do I look it up, in m's top-level lexical environment. but I don’t think that is what you mean. I'm confused. Could you be more concrete? Possibly this may help? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType I'm cc'ing ghc-devs. Simon | -----Original Message----- | From: Eric Seidel [mailto:eseidel@cs.ucsd.edu] | Sent: 23 July 2014 19:01 | To: Simon Peyton Jones | Subject: A couple of GHC-API questions | | Hi Simon, | | I have a couple of questions about how to use GHC’s API properly. | There’s nothing urgent here as we’re making due just fine in | LiquidHaskell, but I’m pretty sure we’re hacking around GHC when we | don’t need to :) | | As you probably know, we basically use GHC to get the Core binders of a | module, and to resolve a bunch of names. Translating to Core has never | been an issue for us as far as I know, but our name-resolution code is | very haphazard. The core of our problems with name-resolution comes | down to resolving the names in specifications that have been imported | from another module, e.g. | | module A where | data Foo | mkFoo :: {v:Int | v >= 0} -> Foo | ... | | module B where | import qualified A | ... | | When we verify module B we have to first resolve all of the types that | were imported from module A, *but* we can’t do that in the context of | module B due to the qualified import. So I’ve been using a slightly | modified version of GHC’s DynamicLoading.lookupRdrNameInModule to | handle the change of context, but this seems to require that we use the | HscInterpreted flag, which causes further problems for a few of our | benchmarks that make use of the C FFI.. This method also only works for | modules where we actually have the source code available, i.e. we have | to use a different method of looking up names to attach specifications | to functions from the base libraries. | | So I guess my question is this: is there a simple way to ask GHC to | resolve the name x in the context of module m, without invoking the | code generator or any other part of GHC’s functionality? I suppose a | more principled solution would be to somehow hook into the .hi files | that GHC generates, but I’m not sure if that’s possible. | | Again, the code we have right now works, it’s just very fragile and I’d | like to clean things up. | | Thanks! | | Eric

2 1

Repositories page
by Simon Peyton Jones 24 Jul '14

24 Jul '14

Austin I know that you have been working on * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git * https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules But what about the main "Repositories" page * https://ghc.haskell.org/trac/ghc/wiki/Repositories which is linked directly from the LH Margin bar? Is this page fully upd to date, including the "Full repository breakdown" table? Presumably not... I'm pretty sure that you said that Repositories/Upstream is fully out of date and should be retired. Also the Git/Submodules page also has a similar table, but with fewer columns. But some of the columns in the Repositories page ("reqd to build", "installed") are still relevant. Shouldn't there be just one master table with all this info? Could you perhaps clear this up --- in the wiki, not by replying to me :)? Thanks There is also https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries, which is useful, and I think is still up to date. Indeed Edward and I have just updated it. But it's not that easy to find. It would be good if the Master Table (see above) had a column for each of the four properties of the boot packages that this page describes. Thanks Simon

1 0

Re: Update Cabal submodule to HEAD (1.21)
by Joachim Breitner 24 Jul '14

24 Jul '14

Hi, Am Samstag, den 19.07.2014, 01:14 +0100 schrieb Edward Z.Yang: > The reason for this is that the builders do not have a sufficiently > recent version of process, which Cabal has upgraded to depend on. > Probably 'cabal update && cabal install process' should bring it up to > date and make it working. Unfortunately, the build system bypasses > Cabal for the bootstrap build of Cabal, so the version dependency range > is not checked. didn’t seem to help just like that. https://api.travis-ci.org/jobs/30346178/log.txt?deansi=true Probably because of "-no-user-package-db". Trying with "cabal install --global" now. > BTW, I noticed the builders are still bootstrapping from 7.4. Since > 7.8 was stabilized recently, we're going to be retiring support for > bootstrapping from 7.4 soon. Upgrade! 7.4 is still the version in the latest Debian stable release, as well as the almost latest Ubuntu LTS release (14.4 is still kinda new). But I guess I can install ghc from a PPA on travis. It doesn’t help with the process problem, though, that also affects 7.6. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 7

Re: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by Alexander Berntsen 24 Jul '14

24 Jul '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 24/07/14 01:29, Andrew Pennebaker wrote: > Like many programming language environments, GHC offers a handy > `-e` option for evaluating an expression, then returning to the > shell. > > $ ghc -e '2 + 2' > > 4 > > One would expect the interpreter, GHCi, to offer a similar flag, > but it surprisingly rejects it. > > ghci -e '2 + 2' > > ghc: on the commandline: cannot use `--interactive' with `-e' > > Usage: For basic information, try the `--help' option. > > > I think this behavior is quite unintuitive--when I pass `-e <exp>` > to ghci, or pass `--interactive -e <exp>` to ghc, I expect the > expression to be evaluated as the leading expression in an > interactive interpreter session. > > > Could we please tweak ghc like this to make it slightly more > intuitive when these flags are used together? Good idea! I'll look into it. But did you mean to post this to the ghc-devs list? I've CC'd them with your entire email intact. Also, in case I forget all about this or fail, you should add a ticket to our Trac system[0]. That way, this won't get lost. Thanks! [0] <https://ghc.haskell.org/trac/ghc/> - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPQxhUACgkQRtClrXBQc7XylgEAqbDrspchvHllACPf9lwrFTbN YenIDCggXbj98NJR5/8BAJUxpkej6T6QV4G+jk9R61nbUOEASEJ+0GBcHLBXpAsw =3/+R -----END PGP SIGNATURE-----

1 0

The haddock / clang problem revisited ... root cause found...
by Mark Lentczner 23 Jul '14

23 Jul '14

tl;dr: - cabal is the culprit - If you have the `Extensions: CPP` directive in your .cabal file, then when invoking haddock, cabal causes every file to be pre-processed twice in sequence. - pre-processing isn't idempotent - when done under clang, it outputs things that ghc. longer: Regarding the ellusive problem whereby haddock for some packages fails on ghc-7.8.3 / haddock-2.14.2 systems with clang (as in OS X 10.9): Bugs were filed for both haddock and cabal: https://github.com/haskell/haddock/issues/284 https://github.com/haskell/cabal/issues/1740 I've been trying to find a work-around before releasing the platform for OS X. In sleuthing this I found the root cause: cabal. Full details here: Root cause of haddock / clang failure <https://gist.github.com/mzero/d4ba11c567977111749a> The correct fix is to change cabal's behavior: Either don't pre-process the fils for Haddock, or don't pass --optghc=-XCPP There is no good work around: We could add -optP-P to all compilations, but that breaks line numbers for everything. We could wrap haddock to remove the --optghc=-XCPP, but that will break hand invocations of haddock. - Mark

2 3

Call for help on testing integer-gmp2 on non-Linux archs
by Herbert Valerio Riedel 23 Jul '14

23 Jul '14

Hello *, As some of you may have already noticed, there's an attempt[1] in the works to reimplement integer-gmp in such a way to avoid overriding GMP's internal memory allocator functions, and thus make it possible to link GHC/integer-gmp compiled programs with other components linked to libgmp which break if GMP's memory allocation goes via GHC's GC. I also hope this will facilitate to ship GHC bindists for Windows with a dynamically linked (& unpatched!) GMP library, to reduce LGPL licencing concerns for resulting GHC compiled programs. So far, I've only been able to test the code on Linux/i386 and Linux/amd64 where it works correctly. Now it'd be interesting to know if integer-gmp2 in its current form works also on non-Linux archs, and if not, what's needed to make it work. Fwiw, I mostly suspect linker-related issues. Therefore, is anyone here interested to help out with making sure GHC+integer-gmp2 builds on Windows, OSX and so on? If so, please get into contact with me! Cheers, hvr [1]: https://ghc.haskell.org/trac/ghc/ticket/9281 https://phabricator.haskell.org/D82

4 6

Looking for list comprehensions use cases
by Jan Stolarek 23 Jul '14

23 Jul '14

Haskellers, recently I've been looking into the possibility of creating some new optimisations for GHC. These would be mostly aimed at list comprehensions. Here's where I need your help: 1. Do you have complex list comprehensions usage examples from real code? By complex I mean nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc. 2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to make them fast enough? Janek

1 0

a little phrustrated
by Richard Eisenberg 22 Jul '14

22 Jul '14

Hi all, I'm trying to use Phab for the first time this morning, and hitting a fair number of obstacles. I'm writing up my experiences here in order to figure out which of these are my fault, which can be fixed, and which are just things to live with; and also to help others who may go down the same path. If relevant, my diff is at https://phabricator.haskell.org/D73 1) I had some untracked files in a submodule repo. I couldn't find a way to get `arc diff` to ignore these, as they appeared to git to be a change in a tracked file (that is, a change to a submodule, which is considered tracked). `git stash` offered no help, so I had to delete the untracked files. This didn't cause real pain (the files were there in error), but it seems a weakness of the system if I can't make progress otherwise. 2) I develop and build in the same tree. This means that I often have a few untracked files in the outer, ghc.git repo that someone hasn't yet added to .gitignore. Thus, I need to say `--allow-untracked` to get `arc diff` to work. I will likely always need `--allow-untracked`, so I looked for a way to get this to be configured automatically. I found https://secure.phabricator.com/book/phabricator/article/arcanist/#configura… , but the details there are sparse. Any advice? 3) The linter picks up and complains about tabs in any of my touched files. I can then write an excuse for every `arc diff` I do, or de-tab the files. In one case, I changed roughly one line in the file (MkCore.lhs) and didn't think it right to de-tab the whole file. Even if I did de-tab the whole file, then my eventual `arc land` would squash the whitespace commit in with my substantive commits, which we expressly don't want. I can imagine a fair amount of git fiddling which would push the whitespace commit to master and then rebase my substantive work on top so that the final, landed, squashed patch would avoid the whitespace changes, but this is painful. And advice on this? Just ignore the lint errors and write silly excuses? Or, is there a way Phab/arc can be smart enough to keep whitespace-only commits (perhaps tagged with the words "whitespace only" in the commit message) separate from other commits when squashing in `arc land`? 4) For better or worse, we don't currently require every file to be tab-free, just some of them. Could this be reflected in Phab's lint settings to avoid the problem in (3)? (Of course, a way to de-tab and keep the history nice would be much better!) 5) In writing my revision description, I had to add reviewers. I assumed these should be comma-separated. This worked and I have updated the Wiki. Please advise if I am wrong. 6) When I looked at my posted revision, it said that the revision was "closed"... and that I had done it! slyfox on IRC informed me that this was likely because I had pushed my commits to a wip/... branch. Is using wip branches with Phab not recommended? Or, can Phab be configured not to close revisions if the commit appears only in wip/... branches? 7) How can I "re-open" my revision? 8) Some time after posting, phaskell tells me that my build failed. OK. This is despite the fact that Travis was able to build the same commit (https://travis-ci.org/ghc/ghc/builds/30066130) I go to find out why it failed, and am directed to build log F3870 (https://phabricator.haskell.org/file/info/PHID-FILE-hz2r4sjamkkrbf7nsz6b/) I can't view the file online, but instead have to download and then ungzip it. Is it possible to view this file directly? Or not have it be compressed? 9) When I do view the build log, I get no answers. The end of the file comes abruptly in the middle of some haddock output, and the closest thing that looks like an error is about a missing link in a haddock tag `$kind_subtyping` in Type.lhs. I didn't touch this file, and I imagine the missing link has been there for some time, so I'm dubious that this is the real problem. Are these log files cut off? 10) More of a question than a phrustration: is there a way to link directly to Trac tickets and/or wiki pages from Phab comments? I like the Phab:D73 syntax from Trac to Phab, and thanks, Austin, for adding the field at the top of Trac tickets to Phab revisions. I did fully expect to hit a few bumps on my first use of this new tool, but it got to the point where I thought I should seek some advice before continuing to muddle through -- hence this email. I do hope my tone is not overly negative: I'm *very* appreciative of the work that many of you do to support GHC's infrastructure, and I look forward to being able to get and provide source code feedback through Phab. We just need to work out some kinks, I think! (Any number of these kinks may be solely my fault, of course.) Many thanks, Richard

8 9

RE: tcInferRho
by Simon Peyton Jones 22 Jul '14

22 Jul '14

Richard You are right; there is something squishy here. The original idea was that a unification variable only stands for a *monotype* (with no for-alls). But our basic story for the type inference engine is tcExpr :: HsExpr -> TcType -> TcM HsExpr' which checks that the expression has the given expected type. To do inference we pass in a unification variable as the "expected type". BUT if the expression actually has a type like (forall a. a->a) -> Int, then the unification variable clearly isn't being unified with a monotype. There are a couple of places where we must "zonk" the expected type, after calling tcExpr, to expose the foralls. A major example is TcExpr.tcInferFun. I say this is squishy because *in principle* we could replace every unification with generating an equality constraint, for later solving. (This does often happen, see TcUnify.uType_defer.) BUT if we generate an equality constraint, the zonking won't work, and the foralls won't be exposed early enough. I wish that the story here was more solid. The original idea of tcInferRho was to have some special cases that did not rely on this squishy "unify with polytype" story. It had a number of special cases, perhaps not enough as you observe. But it does look as if the original goal (which I think was to deal with function applications) doesn't even use it -- it uses tcInferFun instead. So I think you may be right: tcInferRho may not be important. There is a perhaps-significant efficiency question though: it avoids allocating an unifying a fresh unification variable each time. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 18 July 2014 22:00 | To: Simon Peyton Jones | Subject: Re: tcInferRho | | I thought as much, but I can't seem to tickle the bug. For example: | | > {-# LANGUAGE RankNTypes #-} | > | > f :: Int -> Bool -> (forall a. a -> a) -> Int | > f = undefined | > | > x = (3 `f` True) | > | | | GHCi tells me that x's type is `x :: (forall a. a -> a) -> Int`, as we | would hope. If we were somehow losing the higher-rank polymorphism | without tcInferRho, then I would expect something like `(3 `f` True) $ | not)` to succeed (or behave bizarrely), but we get a very sensible type | error | | Couldn't match type 'a' with 'Bool' | 'a' is a rigid type variable bound by | a type expected by the context: a -> a | at /Users/rae/temp/Bug.hs:6:5 | Expected type: a -> a | Actual type: Bool -> Bool | In the second argument of '($)', namely 'not' | In the expression: (3 `f` True) $ not | | So, instead of just adding more cases, I wonder if we can't *remove* | cases, as it seems that the gears turn fine without this function. This | continues to surprise me, but it's what the evidence indicates. Can you | make any sense of this? | | Thanks, | Richard | | | On Jul 18, 2014, at 12:49 PM, Simon Peyton Jones <simonpj(a)microsoft.com> | wrote: | | > You're right, its' an omission. The reason for the special case is | described in the comment on tcInferRho. Adding OpApp would be a Good | Thing. A bit tiresome because we'd need to pass to tcInferApp the | function to use to reconstruct the result HsExpr (currently foldl | mkHsApp, in tcInferApp), so that in the OpApp case it'd reconstruct an | OpApp. | > | > Go ahead and do this if you like | > | > S | > | > | -----Original Message----- | > | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | > | Sent: 17 July 2014 18:48 | > | To: Simon Peyton Jones | > | Subject: tcInferRho | > | | > | Hi Simon, | > | | > | I'm in the process of rejiggering the functions in TcHsType to be | more | > | like those in TcExpr, in order to handle the richer type/kind | language | > | of my branch. | > | | > | I have a question about tcInferRho (TcExpr.lhs:115). It calls | > | tcInfExpr, which handles three special cases of HsExpr, before | > | deferring to tcExpr. The three cases are HsVar, HsPar, and HsApp. | > | What's odd about this is that there are other cases that seem to | belong | > | in this group, like OpApp. After all, (x + y) and ((+) x y) should | > | behave the same in all circumstances, right? I can't find a way to | > | tickle the omission here, so there may not be a bug, but it certainly | > | is a little strange. Can you shed any light? | > | | > | Thanks! | > | Richard | >

2 4

Re: [QuickCheck] Status of Haskell Platform 2014.2.0.0
by Johan Tibell 22 Jul '14

22 Jul '14

On Mon, Jul 21, 2014 at 1:30 AM, Nick Smallbone <nicsma(a)chalmers.se> wrote: > 1. We make sure that tf-random becomes stable and hope it can be > included in the next version of the platform. > > 2. We add a simple TFGen-inspired generator directly to QuickCheck. > > 3. We fix StdGen by replacing it with a TFGen-inspired implementation. > > Number 3 would be best for everyone, but if it doesn't happen maybe > option 2 is the most pragmatic one. I agree that (2) looks like the most pragmatic one.

1 0