haskell: make `ghc`, `cabal-install`, and `stack` visible

Thanks to @peti. Close #10035.

+9 -10
+5 -6
doc/haskell-users-guide.xml
··· 11 11 registered on 12 12 <link xlink:href="http://hackage.haskell.org/">Hackage</link>, but 13 13 strangely enough normal Nix package lookups don't seem to discover 14 - any of them: 14 + any of them, except for the default version of ghc, cabal-install, and stack: 15 15 </para> 16 16 <programlisting> 17 - $ nix-env -qa cabal-install 18 - error: selector ‘cabal-install’ matches no derivations 19 - 20 - $ nix-env -i ghc 21 - error: selector ‘ghc’ matches no derivations 17 + $ nix-env -i alex 18 + error: selector ‘alex’ matches no derivations 19 + $ nix-env -qa ghc 20 + ghc-7.10.2 22 21 </programlisting> 23 22 <para> 24 23 The Haskell package set is not registered in the top-level namespace
+3 -4
nixos/doc/manual/release-notes/rl-1509.xml
··· 135 135 136 136 <listitem> 137 137 <para> 138 - Haskell packages can no longer be found by name, i.e. the commands 139 - <literal>nix-env -qa cabal-install</literal> and <literal>nix-env -i 140 - ghc</literal> will fail, even though we <emphasis>do</emphasis> ship 141 - both <literal>cabal-install</literal> and <literal>ghc</literal>. 138 + Haskell packages can no longer be found by name, except for 139 + <literal>ghc</literal>, <literal>cabal-install</literal>, and 140 + <literal>stack</literal>, even though we do package the whole Hackage. 142 141 The reason for this inconvenience is the sheer size of the Haskell 143 142 package set: name-based lookups such as these would become much 144 143 slower than they are today if we'd add the entire Hackage database
+1
pkgs/top-level/all-packages.nix
··· 3985 3985 haskellPackages = haskell.packages.ghc7102.override { 3986 3986 overrides = config.haskellPackageOverrides or (self: super: {}); 3987 3987 }; 3988 + inherit (haskellPackages) ghc cabal-install stack; 3988 3989 3989 3990 haxe = callPackage ../development/compilers/haxe { 3990 3991 inherit (ocamlPackages) camlp4;