Re: Changing the -package dependency resolution algorithm

2014-08-01 Thread Simon Marlow
On 31/07/2014 15:31, Edward Z. Yang wrote: We need to rethink the shadowing behaviour. It is designed to handle the case where we have the same PackageId (name + version) in two different DBs (e.g. global and local). Shadowing takes the topmost one of these (e.g. local, or rightmost -package-db

Re: Changing the -package dependency resolution algorithm

2014-07-31 Thread Edward Z . Yang
> We need to rethink the shadowing behaviour. It is designed to handle > the case where we have the same PackageId (name + version) in two > different DBs (e.g. global and local). Shadowing takes the topmost one > of these (e.g. local, or rightmost -package-db flag). We can relax this > requ

Re: Changing the -package dependency resolution algorithm

2014-07-31 Thread Simon Marlow
Sorry for not replying to this earlier. I think after our meeting the other day we agreed to keep the existing algorithm but document it better. Here's a stab at describing the spec: 1. compute the set of valid packages, where a package is valid if - all its dependencies are valid - it is

Re: Changing the -package dependency resolution algorithm

2014-07-24 Thread Edward Z . Yang
Good question. I think package environments are the right answer here: GHCi should come preloaded with some special global package environment. Edward Excerpts from John Lato's message of 2014-07-25 00:52:12 +0100: > How would this work with ghci? If I'm understanding correctly, the > proposal

Re: Changing the -package dependency resolution algorithm

2014-07-24 Thread John Lato
How would this work with ghci? If I'm understanding correctly, the proposal means users could no longer do: $ ghci SomeFile.hs and have it work without manually specifying all -package flags. Did I miss something? I think it would work in conjuction with the package environments stuff, provi

Re: Changing the -package dependency resolution algorithm

2014-07-24 Thread Edward Z . Yang
Excerpts from Edward Z. Yang's message of 2014-07-24 15:57:05 +0100: > - It assumes *-hide-all-packages* at the beginning. This scheme > probably works less well without that: now we need some consistent > view of the database to start with. Actually, thinking about this, this dovetails nicel

RE: Changing the -package dependency resolution algorithm

2014-07-24 Thread Simon Peyton Jones
-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Edward Z.Yang | Sent: 24 July 2014 15:57 | To: ghc-devs | Subject: Changing the -package dependency resolution algorithm | | Right now, GHC has a very complex and hard to explain algorithm for | picking packages from the package database whe

Changing the -package dependency resolution algorithm

2014-07-24 Thread Edward Z . Yang
Right now, GHC has a very complex and hard to explain algorithm for picking packages from the package database when you give it a pile of -package/-package-id/-{hide,ignore,trust,distrust}-package flags. Roughly, it currently does something like this. 1. Concatenate all of the package databases in