- ghc-devs - Haskell.org

RE: A couple of GHC-API questions
by Eric Seidel 24 Jul '14

24 Jul '14

Sorry for the double email Simon, I hadn’t signed up for ghc-devs so my response was rejected.. --- Thanks for getting back to me so quickly! On July 24, 2014 at 0:33:44, Simon Peyton Jones (simonpj(a)microsoft.com) wrote: > 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. Sorry for the confusion, I’m actually asking about how to get the right Name. When we first parse a specification, all of the TyCons etc. are plain Strings, i.e. we have a type data RefType tycon tyvar = … type ParsedRefType = RefType String String But we don’t want to deal with Strings, we want to use GHC’s TyCons and TyVars type GHCRefType = RefType TyCon TyVar so we need a function that maps Strings to Names (and then finding the TyCon is easy). This is what I mean by “resolving” the types. For single-module programs this is trivial, we can do something like resolve x = do rn <- hscParseIdentifier x hscTcRnLookupRdrName rn For multi-module programs it becomes trickier because we also have to resolve the types that we’ve imported from other modules. So, using my example from earlier, when we type-check module B we have to turn the String “Foo” into the Name A.Foo. This is problematic because module B imported module A qualified, so “Foo” is not in scope inside B but “A.Foo” is. I believe GHC might be avoiding this issue via the .hi files, so when you import a Type from another module, it is already using TyCons instead of Strings. > 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 think this is almost exactly what I mean, except that I want to be able to look up the unqualified “x” as well as the qualified “SomeModuleThatMayHaveBeenRenamed.x” inside m’s top-level environment. This is more or less what the DynamicLoading.lookupRdrNameInModuleForPlugins function that I’ve copied and tweaked does, but it requires the presence of the original source code. I’m hoping there may be some other function out there that does the same thing without requiring the source code, so we can use it for the base libraries as well. > I'm confused. Could you be more concrete? > Possibly this may help? https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/NameType Thanks for the reference, I’m familiar with most of the info there already from browsing GHC’s source, but this is laid out much more newcomer-friendly manner :) Hopefully I’ve made my question a bit clearer. Eric

1 0

Re: Removing GHC's dependency on Cabal
by Yuri de Wit 24 Jul '14

24 Jul '14

On Thu, Jul 24, 2014 at 11:59 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > On Thu, Jul 24, 2014 at 10:55 AM, Simon Peyton Jones < > simonpj(a)microsoft.com> wrote: > >> To me it seems simple and obvious! Why are we going round the houses to >> do something so simple? > > > So cabal can maintain its conceit that it supports more than just ghc. > I don't understand this as an argument against the ghc-db library, which to me also seems the simple and obvious solution. Having a ghc-db library will mean one of two options: 1. The *ghc-db* is GHC-specific and will be used by the GHC specific wrappers in Cabal: doesn't cabal already deals with each compiler differently? 2. The ghc-db is really *hs-db* and a library contract that can be reused by all haskell compilers (i.e. part of The Haskell Cabal) In both cases, the assumption is that ghc-db/hs-db should have a stable API. Now, choosing option (1) doesn't eliminate option (2). When and if there is a broad agreement across all compilers, ghc-db could become hs-db and be incorporate into The Haskell Cabal. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b(a)gmail.com > ballbery(a)sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > cabal-devel mailing list > cabal-devel(a)haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > >

1 0

Removing GHC's dependency on Cabal
by Edward Z. Yang 24 Jul '14

24 Jul '14

Hello all, I know Duncan and SPJ have been keen on removing GHC's dependency on Cabal for some time now. Simon and I were chatting about the subject today, and we wanted to propose an alternative way of doing the remodularization. Here are diagrams of the proposals: http://web.mit.edu/~ezyang/Public/ghc-cabal-refactor.pdf As I understand it, Duncan's proposal is to take the current constellation of libraries, and just remove the dependency to Cabal from GHC and bin-package-db, duplicating data structures as necessary. ghc-pkg is now responsible for converting between Cabal's format and GHC's format. Simon suggested that this 'ghc-pkg' functionality (which specifies the database format and how to handle it) should be placed in a library of its own. So in the third graph, we have a new package ghc-db which everyone depends on. Cabal no longers shells out to ghc-pkg to modify database, instead it directly converts to ghc-db's format and then invokes library functions in the library. We were wondering if there was any reason to prefer the former situation over the latter. One answer might be that Cabal is less keen to have a dependency on a very GHC specific library (although the ghc-pkg dependency is quite a fairly tightly coupled one.) Cheers, Edward

4 4

Re: At long last: 2014.2.0.0 Release Candidate 1
by Mark Lentczner 24 Jul '14

24 Jul '14

On Thu, Jul 24, 2014 at 5:30 AM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > Errrr. Whoever is making the Mac bindist should take care to avoid any > MacPorts (or for that matter Homebrew) components slipping in to it; this > will cause problems down the road. > That would be makin' that bindist! And your advice about other package systems is the same as my own. The bindist used in the release was built on a very clean machine that has only stock OS X and stock Xcode installed... never Homebrew or MacPorts. That machine doesn't even have a /opt directory! - Mark

1 0

RE: GHC contribution guidelines and infrastructure talk on 6th September at HIW?
by Jost Berthold 24 Jul '14

24 Jul '14

(Sorry for joining this late... I figured we would be in dialogue off the list eventually) Joachim wrote and posted a proposal, and I think this proposal is indeed a good idea (and one of the purposes of HIW, definite yes). We shall make room for it in the programme, possibly in the last session, which can turn into the "Haskell release discussion evening". Best regards Jost On 07/22/2014 11:06 AM, ghc-devs-request(a)haskell.org wrote: > Date: Tue, 22 Jul 2014 08:38:22 +0000 > From: Simon Peyton Jones <simonpj(a)microsoft.com> > To: Mark Lentczner <mark.lentczner(a)gmail.com>, "ghc-devs(a)haskell.org" > <ghc-devs(a)haskell.org> > Subject: RE: GHC contribution guidelines and infrastructure talk on > 6th September at HIW? > Message-ID: > <618BE556AADD624C9C918AA5D5911BEF10435304(a)DB3PRD3001MB020.064d.mgd.msft.net> > > Content-Type: text/plain; charset="utf-8" > > I think such a discussion would be a Good Thing, and just what HIW is for. > > Simon > > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Mark Lentczner > Sent: 22 July 2014 02:03 > To: ghc-devs(a)haskell.org > Subject: Re: GHC contribution guidelines and infrastructure talk on 6th September at HIW? > > On a related front... I don't have a talk to give (hence I didn't submit a proposal)... But I'd love it if some of us could have a group discussion about coordinating releases, and our approach to putting out "Haskell": > > In short, we see it as several related peices (GHC, Cabal, Haddock, core libs, platform, etc...) but my guess is that most developers considering using Haskell see it as one thing: "Can I haz the Haskellz on my machine? kthxbai?" Therefore, I think we could put some thought into how we manage these pieces into a cohesive whole whose release more or less "just works". > > Not sure if this should be a "session", a "workshop", a long hallway disucssion, a night of good food and beer, or what. I'm happy to put some effort into organizing, and setting the context for the discussion. > > - Mark

3 3

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