Branch: refs/heads/haskellPackagesFixpoint
Home: https://github.com/NixOS/nixpkgs
Commit: d4bd4650d666c44e38f3629ae0371531fddb25fa
https://github.com/NixOS/nixpkgs/commit/d4bd4650d666c44e38f3629ae0371531fddb25fa
Author: Russell O'Connor <[email protected]>
Date: 2014-05-08 (Thu, 08 May 2014)
Changed paths:
M pkgs/top-level/haskell-defaults.nix
M pkgs/top-level/haskell-packages.nix
Log Message:
-----------
Rework the knot-tying code for defining Haskell packages.
The existing knot-tying code I felt was a bit incoherent with result,
finalReturn, self, refering to different various forms of the "haskellPackages"
value and often
different forms in the same place.
This commit instills some object-oriented discipline to the construction of
hasekllPackages using a small number of fundamental OO concepts:
* An class is a open recursive function of the form (self : fooBody) where
fooBody is a set.
* An instance of a class is the fixed point of the class.
This value is sometimes refered to as an object and the values in the
resulting set are sometimes refered to as methods.
* A class, foo = self : fooBody, can be extended by an extension which is a
function bar = (self : super : barBody) where barBody a set of overrides for
fooBody.
The result of a class extension is a new class whose value is self : foo self
// bar self (foo self).
The super parameter gives access to the original methods that barBody may be
overriding.
This commit turns the haskell-packages value into a "class".
The knot-tying, a.k.a the object instanitation, is moved into
haskells-defaults. The "finalReturn" is no longer needed and is eliminated
from the body of
haskell-packages. All the work done by prefFun is moved to haskell-defaults, so
that parameter is eliminated form haskell-packages. Notice that the old
prefFun took
two pameters named "self" and "super", but both parameters got passed the same
value "result". There seems to have been some confusion in the old code.
Inside haskell-defaults, the haskell-packages class is extended twice before
instantiation. The first extension is done using prefFun argument.
The second extension is done the extension argument, which is a renamed version
of extraPrefs.
This two stage approach means that extension's super gets access to the post
"perfFun" object while previously the extraPrefs only had access to the pre
"prefFun"
object. Also the extension function has access to both the super (post
"perfFun") object and to self, the final object. With extraPrefs, one needed
to use the
"finalReturn" of the haskell packages to get access to the final object. Due
to significant changes in semantics, I thought it best to replace extraPrefs
with
extension so that people using extraPrefs know to update thier cod.
Lastly, all the Prefs functions have renamed the "self" parameter to "super".
This is because "self" was never actually a self-reference in the object
oriented sense
of the word. For example
Cabal_1_18_1_3 = self.Cabal_1_18_1_3.override { deepseq =
self.deepseq_1_3_0_2; };
doesn't actually make sense from an object oriented standpoint because, barring
further method overriding, the value of Cabal_1_18_1_3 would be trying to
override it's
own value which simply causes a loop exception. Thankfully all these uses of
self were really uses of super:
Cabal_1_18_1_3 = super.Cabal_1_18_1_3.override { deepseq =
super.deepseq_1_3_0_2; };
In this notation the overriden Cabal_1_18_1_3 method calls the Cabal_1_18_1_3
of the super-class, which is a well-founded notion.
Below is an example use of using "extension" parameter
{
packageOverrides = pkgs : {
testHaskellPackages = pkgs.haskellPackages.override {
extension = self : super : {
transformers_0_4_1_0 = self.cabal.mkDerivation (pkgs: {
pname = "transformers";
version = "0.4.1.0";
sha256 = "0jlnz86f87jndv4sifg1zpv5b2g2cxy1x2575x727az6vyaarwwg";
meta = {
description = "Concrete functor and monad transformers";
license = pkgs.stdenv.lib.licenses.bsd3;
platforms = pkgs.ghc.meta.platforms;
maintainers = [ pkgs.stdenv.lib.maintainers.andres ];
};
});
transformers = self.transformers_0_4_1_0;
lensFamilyCore = super.lensFamilyCore.override { transformers =
self.transformers_0_3_0_0; };
};
};
};
}
Notice the use of self in the body of the override of the transformers method
which references the newly defined transformers_0_4_1_0 method.
With the previous code, one would have to instead akwardly write
transformers = super.finalReturn.transformers_0_4_1_0;
or use a rec clause, which would prevent futher overriding of
transformers_0_4_1_0.
_______________________________________________
nix-commits mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-commits
