The generated js files view-source:https://hackage.haskell.org/package/base-4.16.3.0/docs/quick-jump.min.js and view-source:https://hackage.haskell.org/package/base-4.17.0.0/docs/quick-jump.min.js are different -- presumably from different versions of haddock. Perhaps the newer version of haddock creates a file that doesn't work well with the way the index page is created?
Indeed, if one opens the broken page and just calls e.g. quickNav.init("/package/base-4.17.0.0/docs",function(t){console.log("hi");t();});
from the console, then it just returns undefined. Doing the same thing on the working page (with the different included quick-jump.min) will hit the callback and log to the console.
So a regression in haddock, which should probably be moved on.
My tendency is to look for the simplest possible solution in the design space that addresses the underlying problem. Here I would be happy to have logic even that noticed if there was an env file around, and if there was, printed, along with the current output a notice that the packages displayed by list
would not correspond to what a ghci session had in scope, due to this env file, and printed the location of the env file so a user could go and read it for themselves.
I really don't see why a
ghc --list-visible-packages
flag wouldn't solve this going forward.
Because the problem is that the existing command does not do what people expect, and there is no signpost in the output of that command that it does not do what people expect.
I agree that there will be versions that exist that continue to not do what people expect. However, by that argument, no ux improvement could be made ever, because there will be cases where older versions do not have it.
I agree that users won't be able to rely on it -- however, there are users who have been taught to rely on it and get confused. For those users, improving the immediate situation seems like a straightforward win.
What I'm suggesting seems terribly easy to implement, and has no particular downside. I don't understand the squeamishness.
I understand your view that this is worth doing. As I said, in my judgement, I am not enthused or unenthused about this, and I'm noting this just to clarify, since in the description this was opened in, I was pegged as endorsing this. I think enforcing global coherence to comply with the spec is a fine fix to ghc. I don't know how much work it would be, or if that work is worth the effort. I don't think that the lack of this has been anything but a weird curiosity at worst, so it does not feel urgent.
Ah that's the source of the confusion. The root issue is not simply "being able to discover which packages GHC knows about" but rather that people have been taught for a very long time that the way to do that is ghc-pkg list
. So they type ghc-pkg list
and get output which is extremely misleading compared to what much documentation still says, and compared to their expectations.
I would be perfectly happy with something as simple as ghc-pkg list
figuring out which environment file would be discovered by ghc, and just literally running a "cat" of its contents (appropriately denoted as such) following its current output.
But the issue is really that ghc-pkg list
appears to tell users what packages ghc knows about, but that this does not correspond to what will happen when they run ghci and find out what modules are actually in scope. It has been extremely confusing to many users for some years now that this happens, and I'd really like there to be some fix for this. Any command that is not ghc-pkg list
no matter how clever or powerful it is will not solve this. But a very crude change that is not at all clever to ghc-pkg list
will solve this.
To be clear, I'm interested in a ghc proposal for "forward-decls" of orphans. I don't mind ghc actually learning how to enforce the global coherence check specified in the semantics of haskell, but I'm not particularly worried about that either way.
@mpickering I don't understand, on reviewing the previous comments, what the outstanding question is.
If you could say what the question is, then this can be cleared up. If it isn't clearly articulated, then it will never be answered, and this issue will be postponed indefinitely
I definitely think that any command besides list should not take env files into account. Otherwise tools that interact with ghc-pkg (including cabal itself) might start to have very unexpected behavior.
Its just the case that when there's an env file, list
should make the information it provides available to a user, nicely, and in a way that explains what's going on.
I think that the expected behavior would be that the ghc-pkg list should, when making use of an environment file, first, loudly proclaim it is doing such a thing, and second, only list as exposed those packages specified in the environment file.
I.e. its default behavior should be to present the packages to the user the same way they will experience them if they open ghci.
gershomb (591d3328) at 25 Mar 18:29
Update libraries/base/Data/Traversable.hs
I received replies from Jeremy Gibbons, Russell O'Connor, and Mauro Jaskelioff. There seems to be consensus that there's no proof of the statement in question, and the section appears confusingly worded. There's a bit of varying takes on exactly what restricted setting something like what vdukhovni suggests could be proved. But that said, I think the discussion's conclusions should lend themselves to approving this PR, given the current state of knowledge.
As I understand, if all the ghc libs provide abi hashes, then cabal-install will use them in generating its own abi hashes, and as a result, bugs where cabal-install attempts to use things that appear correct, but are not (including with plugins and reinstallable ghc, or.. really.. whatever) will not occur.
I also agree that in the design of a plugin-depends, we should record the precise ghc the plugin was built with, via some mechanism. This isn't for the solver. It's just so we don't think the darn thing has already been built! :-)
I don't think there's much to be done for people managing libs on their own (i.e. without cabal install). They will simply need to manually manage entirely different package databases for every particular build of ghc they have lying around, as I imagine they do now.
So "An Investigation of the Laws of Traversals" does not require that last law to hold, and confirms that purity matches identity. However it does not show that the laws are implied by other laws -- it just does not consider them.
It might better to also link to the more recent paper: https://www.cs.ox.ac.uk/jeremy.gibbons/publications/uitbaf.pdf
This paper still requires naturality laws (see page 4). The future work section of that paper indicates that for many datatypes, naturality may be automatic, but leaves this as an open question.
I will ask around a bit, but I think the state of research is that this is a wrong claim as written, and the related claims are open questions.
It could be. I don't know a proof either way off hand. I know that the cited paper does not have this claim, and no other paper I know has this claim. So the citation is certainly wrong! And even if it were the claim, it would be a different claim than the one the docs currently make. Much like wikipedia, we should discourage "original research" in documentation like this.
gershomb (46f0bcbd) at 06 Feb 04:36
Remove wrong claim about naturality law.
gershomb (549292eb) at 06 Feb 04:36
gershomb (28852b9d) at 06 Feb 04:36
Avoid repeated zonking and tidying of types in relevant_bindings
gershomb (ee5c4f9d) at 06 Feb 04:36