2012-05-14 15:09:05 +02:00
|
|
|
# Haskell / GHC infrastructure in Nixpkgs
|
|
|
|
|
#
|
|
|
|
|
# In this file, we
|
|
|
|
|
#
|
|
|
|
|
# * define sets of default package versions for each GHC compiler version,
|
|
|
|
|
# * associate GHC versions with bootstrap compiler versions and package defaults.
|
|
|
|
|
#
|
|
|
|
|
# The actual Haskell packages are composed in haskell-packages.nix. There is
|
|
|
|
|
# more documentation in there.
|
|
|
|
|
|
2014-05-07 15:13:48 +02:00
|
|
|
{ makeOverridable, lowPrio, hiPrio, stdenv, pkgs, newScope, config, callPackage } : rec {
|
2012-05-14 15:09:05 +02:00
|
|
|
|
|
|
|
|
# Preferences functions.
|
|
|
|
|
#
|
|
|
|
|
# Change these if you want to change the default versions of packages being used
|
|
|
|
|
# for a particular GHC version.
|
|
|
|
|
|
2012-06-04 11:46:26 +02:00
|
|
|
ghcHEADPrefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_future self // {
|
2012-06-11 17:07:33 +02:00
|
|
|
haskellPlatform = null;
|
2014-05-09 04:01:36 +02:00
|
|
|
extensibleExceptions = self.extensibleExceptions_0_1_1_4;
|
2014-05-05 22:34:58 +02:00
|
|
|
binary_0_7_1_0 = null;
|
2012-06-04 11:46:26 +02:00
|
|
|
};
|
2012-05-14 15:09:05 +02:00
|
|
|
|
2013-05-12 15:44:43 +02:00
|
|
|
ghc763Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2013_2_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2013_2_0_0;
|
|
|
|
|
extensibleExceptions = self.extensibleExceptions_0_1_1_4;
|
2013-05-12 15:44:43 +02:00
|
|
|
};
|
|
|
|
|
|
2012-11-06 18:07:38 +01:00
|
|
|
ghc742Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2012_4_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2012_4_0_0;
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-10-03 10:00:45 +02:00
|
|
|
};
|
|
|
|
|
|
2012-05-29 22:16:16 +02:00
|
|
|
ghc741Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2012_2_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2012_2_0_0;
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
2012-07-15 21:48:17 +02:00
|
|
|
ghc722Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2012_2_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2012_2_0_0;
|
|
|
|
|
deepseq = self.deepseq_1_3_0_2;
|
|
|
|
|
cabalInstall_0_14_0 = super.cabalInstall_0_14_0.override { Cabal = self.Cabal_1_14_0; };
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; };
|
|
|
|
|
cabalInstall_1_20_0_1 = super.cabalInstall_1_20_0_1.override { HTTP = self.HTTP_4000_2_14; };
|
|
|
|
|
cabalInstall = super.cabalInstall_0_14_0.override { Cabal = self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
|
|
|
|
prettyShow = self.prettyShow_1_2;
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-29 14:00:25 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 14:00:25 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-07-15 21:48:17 +02:00
|
|
|
};
|
2012-05-14 15:09:05 +02:00
|
|
|
|
2012-07-15 21:48:17 +02:00
|
|
|
ghc721Prefs = ghc722Prefs;
|
2012-05-14 15:09:05 +02:00
|
|
|
|
|
|
|
|
ghc704Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2011_4_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2011_4_0_0;
|
|
|
|
|
cabalInstall_0_14_0 = super.cabalInstall_0_14_0.override { Cabal = self.Cabal_1_14_0; };
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; };
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
|
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
prettyShow = self.prettyShow_1_2;
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
|
|
|
|
Cabal_1_18_1_3 = super.Cabal_1_18_1_3.override { deepseq = self.deepseq_1_3_0_2; };
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-15 19:40:48 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 13:01:34 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ghc703Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2011_2_0_1 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2011_2_0_1;
|
|
|
|
|
cabalInstall_0_14_0 = super.cabalInstall_0_14_0.override { Cabal = self.Cabal_1_14_0; zlib = self.zlib_0_5_3_3; };
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; zlib = self.zlib_0_5_3_3; };
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
|
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
prettyShow = self.prettyShow_1_2;
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
|
|
|
|
Cabal_1_18_1_3 = super.Cabal_1_18_1_3.override { deepseq = self.deepseq_1_3_0_2; };
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-15 19:40:48 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 13:01:34 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ghc702Prefs = ghc701Prefs;
|
|
|
|
|
|
|
|
|
|
ghc701Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2011_2_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2011_2_0_0;
|
|
|
|
|
cabalInstall_0_14_0 = super.cabalInstall_0_14_0.override { Cabal = self.Cabal_1_14_0; zlib = self.zlib_0_5_3_3; };
|
|
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override { Cabal = self.Cabal_1_16_0_3; zlib = self.zlib_0_5_3_3; };
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
|
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
prettyShow = self.prettyShow_1_2;
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
|
|
|
|
Cabal_1_18_1_3 = super.Cabal_1_18_1_3.override { deepseq = self.deepseq_1_3_0_2; };
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-15 19:40:48 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 13:01:34 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ghc6123Prefs = ghc6122Prefs;
|
|
|
|
|
|
|
|
|
|
ghc6122Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2010_2_0_0 self // {
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
haskellPlatform = super.haskellPlatform_2010_2_0_0;
|
2014-05-09 04:01:36 +02:00
|
|
|
mtl1 = self.mtl_1_1_0_2;
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
|
|
|
|
deepseq = self.deepseq_1_1_0_2;
|
2012-05-14 15:09:05 +02:00
|
|
|
# deviating from Haskell platform here, to make some packages (notably statistics) compile
|
2014-05-09 04:01:36 +02:00
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
Cabal = self.Cabal_1_16_0_3;
|
|
|
|
|
zlib = self.zlib_0_5_3_3;
|
|
|
|
|
mtl = self.mtl_2_1_2;
|
|
|
|
|
HTTP = self.HTTP_4000_1_1.override { mtl = self.mtl_2_1_2; };
|
2013-06-15 12:12:08 +02:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-15 19:40:48 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 13:01:34 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ghc6121Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2010_1_0_0 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2010_1_0_0;
|
|
|
|
|
mtl1 = self.mtl_1_1_0_2;
|
|
|
|
|
extensibleExceptions = self.extensibleExceptions_0_1_1_0;
|
|
|
|
|
deepseq = self.deepseq_1_1_0_2;
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
2013-03-09 12:36:51 +01:00
|
|
|
# deviating from Haskell platform here, to make some packages (notably statistics) compile
|
2014-05-09 04:01:36 +02:00
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
cabal2nix = super.cabal2nix.override { Cabal = self.Cabal_1_16_0_3; hackageDb = self.hackageDb.override { Cabal = self.Cabal_1_16_0_3; }; };
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
Cabal = self.Cabal_1_16_0_3;
|
|
|
|
|
zlib = self.zlib_0_5_3_3;
|
|
|
|
|
mtl = self.mtl_2_1_2;
|
|
|
|
|
HTTP = self.HTTP_4000_1_1.override { mtl = self.mtl_2_1_2; };
|
2013-06-15 12:12:08 +02:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
quickcheckIo = super.quickcheckIo.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
|
|
|
|
QuickCheck = self.QuickCheck2;
|
2013-12-15 19:40:48 +01:00
|
|
|
};
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
hspecExpectations = super.hspecExpectations.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
HUnit = self.HUnit_1_2_5_2;
|
2013-12-29 13:01:34 +01:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
ghc6104Prefs =
|
2014-05-09 04:01:36 +02:00
|
|
|
self : super : super.haskellPlatformArgs_2009_2_0_2 self // {
|
|
|
|
|
haskellPlatform = self.haskellPlatform_2009_2_0_2;
|
|
|
|
|
mtl = self.mtl1;
|
|
|
|
|
mtl1 = self.mtl_1_1_0_2;
|
|
|
|
|
extensibleExceptions = self.extensibleExceptions_0_1_1_0;
|
|
|
|
|
text = self.text_0_11_0_6;
|
|
|
|
|
deepseq = self.deepseq_1_1_0_2;
|
|
|
|
|
monadPar = self.monadPar_0_1_0_3;
|
2013-03-09 12:36:51 +01:00
|
|
|
# deviating from Haskell platform here, to make some packages (notably statistics) compile
|
2014-05-09 04:01:36 +02:00
|
|
|
jailbreakCabal = super.jailbreakCabal.override { Cabal = self.disableTest self.Cabal_1_14_0; };
|
|
|
|
|
binary = self.binary_0_6_0_0;
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
cabalInstall_1_16_0_2 = super.cabalInstall_1_16_0_2.override {
|
2014-05-09 04:01:36 +02:00
|
|
|
Cabal = self.Cabal_1_16_0_3;
|
|
|
|
|
zlib = self.zlib_0_5_3_3;
|
|
|
|
|
mtl = self.mtl_2_1_2;
|
|
|
|
|
HTTP = self.HTTP_4000_1_1.override { mtl = self.mtl_2_1_2; };
|
2013-06-15 12:12:08 +02:00
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskeline = self.haskeline_0_7_1_1;
|
|
|
|
|
terminfo = self.terminfo_0_3_2_6;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# Abstraction for Haskell packages collections
|
|
|
|
|
packagesFun = makeOverridable
|
|
|
|
|
({ ghcPath
|
|
|
|
|
, ghcBinary ? ghc6101Binary
|
|
|
|
|
, prefFun
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
, extension ? (self : super : {})
|
2012-05-14 15:09:05 +02:00
|
|
|
, profExplicit ? false, profDefault ? false
|
|
|
|
|
, modifyPrio ? lowPrio
|
2013-12-02 21:33:21 +01:00
|
|
|
, extraArgs ? {}
|
2012-05-14 15:09:05 +02:00
|
|
|
} :
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
let haskellPackagesClass = import ./haskell-packages.nix {
|
|
|
|
|
inherit pkgs newScope modifyPrio;
|
|
|
|
|
enableLibraryProfiling =
|
|
|
|
|
if profExplicit then profDefault
|
|
|
|
|
else config.cabal.libraryProfiling or profDefault;
|
|
|
|
|
ghc = callPackage ghcPath ({ ghc = ghcBinary; } // extraArgs);
|
|
|
|
|
};
|
2014-05-09 04:01:36 +02:00
|
|
|
haskellPackagesPrefsClass = self : let super = haskellPackagesClass self; in super // prefFun self super;
|
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.
2014-05-08 18:01:45 +02:00
|
|
|
haskellPackagesExtensionClass = self : let super = haskellPackagesPrefsClass self; in super // extension self super;
|
|
|
|
|
haskellPackages = haskellPackagesExtensionClass haskellPackages;
|
|
|
|
|
in haskellPackages);
|
2012-05-14 15:09:05 +02:00
|
|
|
|
|
|
|
|
defaultVersionPrioFun =
|
|
|
|
|
profDefault :
|
2012-09-19 19:56:56 +02:00
|
|
|
if config.cabal.libraryProfiling or false == profDefault
|
2012-05-14 15:09:05 +02:00
|
|
|
then (x : x)
|
|
|
|
|
else lowPrio;
|
|
|
|
|
|
|
|
|
|
packages = args : let r = packagesFun args;
|
|
|
|
|
in r // { lowPrio = r.override { modifyPrio = lowPrio; };
|
2014-05-07 15:13:48 +02:00
|
|
|
highPrio = r.override { modifyPrio = hiPrio; };
|
2012-05-14 15:09:05 +02:00
|
|
|
noProfiling = r.override { profDefault = false;
|
|
|
|
|
profExplicit = true;
|
|
|
|
|
modifyPrio = defaultVersionPrioFun false; };
|
|
|
|
|
profiling = r.override { profDefault = true;
|
|
|
|
|
profExplicit = true;
|
|
|
|
|
modifyPrio = defaultVersionPrioFun true; };
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# Binary versions of GHC
|
|
|
|
|
#
|
|
|
|
|
# GHC binaries are around for bootstrapping purposes
|
|
|
|
|
|
|
|
|
|
# If we'd want to reactivate the 6.6 and 6.8 series of ghc, we'd
|
|
|
|
|
# need to reenable an old binary such as this.
|
|
|
|
|
/*
|
|
|
|
|
ghc642Binary = lowPrio (import ../development/compilers/ghc/6.4.2-binary.nix {
|
|
|
|
|
inherit fetchurl stdenv ncurses gmp;
|
|
|
|
|
readline = if stdenv.system == "i686-linux" then readline4 else readline5;
|
|
|
|
|
perl = perl58;
|
|
|
|
|
});
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
ghc6101Binary = lowPrio (callPackage ../development/compilers/ghc/6.10.1-binary.nix {
|
|
|
|
|
gmp = pkgs.gmp4;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
ghc6102Binary = lowPrio (callPackage ../development/compilers/ghc/6.10.2-binary.nix {
|
|
|
|
|
gmp = pkgs.gmp4;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
ghc6121Binary = lowPrio (callPackage ../development/compilers/ghc/6.12.1-binary.nix {
|
|
|
|
|
gmp = pkgs.gmp4;
|
|
|
|
|
});
|
|
|
|
|
|
|
|
|
|
ghc704Binary = lowPrio (callPackage ../development/compilers/ghc/7.0.4-binary.nix {
|
|
|
|
|
gmp = pkgs.gmp4;
|
|
|
|
|
});
|
|
|
|
|
|
2012-09-13 15:48:48 +02:00
|
|
|
ghc742Binary = lowPrio (callPackage ../development/compilers/ghc/7.4.2-binary.nix {
|
|
|
|
|
gmp = pkgs.gmp4;
|
|
|
|
|
});
|
|
|
|
|
|
2012-05-14 15:09:05 +02:00
|
|
|
ghc6101BinaryDarwin = if stdenv.isDarwin then ghc704Binary else ghc6101Binary;
|
|
|
|
|
ghc6121BinaryDarwin = if stdenv.isDarwin then ghc704Binary else ghc6121Binary;
|
|
|
|
|
|
|
|
|
|
# Compiler configurations
|
|
|
|
|
#
|
|
|
|
|
# Here, we associate compiler versions with bootstrap compiler versions and
|
|
|
|
|
# preference functions.
|
|
|
|
|
|
|
|
|
|
packages_ghc6104 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/6.10.4.nix;
|
|
|
|
|
prefFun = ghc6104Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc6121 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/6.12.1.nix;
|
|
|
|
|
prefFun = ghc6121Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc6122 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/6.12.2.nix;
|
|
|
|
|
prefFun = ghc6122Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc6123 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/6.12.3.nix;
|
|
|
|
|
prefFun = ghc6123Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# Will never make it into a platform release, severe bugs; leave at lowPrio.
|
|
|
|
|
packages_ghc701 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.0.1.nix;
|
|
|
|
|
prefFun = ghc701Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc702 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.0.2.nix;
|
|
|
|
|
prefFun = ghc702Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc703 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.0.3.nix;
|
|
|
|
|
prefFun = ghc703Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# The following items are a bit convoluted, but they serve the
|
|
|
|
|
# following purpose:
|
|
|
|
|
# - for the default version of GHC, both profiling and
|
|
|
|
|
# non-profiling versions should be built by Hydra --
|
|
|
|
|
# therefore, the _no_profiling and _profiling calls;
|
|
|
|
|
# - however, if a user just upgrades a profile, then the
|
|
|
|
|
# cabal/libraryProfiling setting should be respected; i.e.,
|
|
|
|
|
# the versions not matching the profiling config setting
|
|
|
|
|
# should have low priority -- therefore, the use of
|
|
|
|
|
# defaultVersionPrioFun;
|
|
|
|
|
# - it should be possible to select library versions that
|
|
|
|
|
# respect the config setting using the standard
|
|
|
|
|
# packages_ghc704 path -- therefore, the additional
|
|
|
|
|
# call in packages_ghc704, without recurseIntoAttrs,
|
|
|
|
|
# so that Hydra doesn't build these.
|
|
|
|
|
|
|
|
|
|
packages_ghc704 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.0.4.nix;
|
|
|
|
|
ghcBinary = ghc6101BinaryDarwin;
|
|
|
|
|
prefFun = ghc704Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc721 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.2.1.nix;
|
|
|
|
|
ghcBinary = ghc6121BinaryDarwin;
|
|
|
|
|
prefFun = ghc721Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc722 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.2.2.nix;
|
|
|
|
|
ghcBinary = ghc6121BinaryDarwin;
|
|
|
|
|
prefFun = ghc722Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc741 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.4.1.nix;
|
|
|
|
|
ghcBinary = ghc6121BinaryDarwin;
|
|
|
|
|
prefFun = ghc741Prefs;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
packages_ghc742 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.4.2.nix;
|
|
|
|
|
ghcBinary = ghc6121BinaryDarwin;
|
2012-10-03 10:00:45 +02:00
|
|
|
prefFun = ghc742Prefs;
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
|
|
|
|
|
2012-08-13 16:29:01 +02:00
|
|
|
packages_ghc761 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.6.1.nix;
|
|
|
|
|
ghcBinary = ghc704Binary;
|
2013-05-12 15:44:43 +02:00
|
|
|
prefFun = ghc763Prefs;
|
2012-08-13 16:29:01 +02:00
|
|
|
};
|
|
|
|
|
|
2013-01-29 20:40:53 +01:00
|
|
|
packages_ghc762 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.6.2.nix;
|
|
|
|
|
ghcBinary = ghc704Binary;
|
2013-05-12 15:44:43 +02:00
|
|
|
prefFun = ghc763Prefs;
|
2013-01-29 20:40:53 +01:00
|
|
|
};
|
|
|
|
|
|
2013-04-21 20:10:27 +02:00
|
|
|
packages_ghc763 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.6.3.nix;
|
|
|
|
|
ghcBinary = ghc704Binary;
|
2013-05-12 15:44:43 +02:00
|
|
|
prefFun = ghc763Prefs;
|
2013-04-21 20:10:27 +02:00
|
|
|
};
|
|
|
|
|
|
2014-04-11 21:28:55 +02:00
|
|
|
packages_ghc782 =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/7.8.2.nix;
|
2014-03-06 11:40:51 +01:00
|
|
|
ghcBinary = ghc742Binary;
|
2014-05-05 22:25:10 +02:00
|
|
|
prefFun = ghcHEADPrefs;
|
2014-03-06 11:40:51 +01:00
|
|
|
};
|
|
|
|
|
|
2012-05-14 15:09:05 +02:00
|
|
|
# Reasonably current HEAD snapshot. Should *always* be lowPrio.
|
|
|
|
|
packages_ghcHEAD =
|
|
|
|
|
packages { ghcPath = ../development/compilers/ghc/head.nix;
|
2014-05-03 11:18:17 +02:00
|
|
|
ghcBinary = pkgs.haskellPackages.ghcPlain;
|
2012-05-14 15:09:05 +02:00
|
|
|
prefFun = ghcHEADPrefs;
|
2013-12-02 21:33:21 +01:00
|
|
|
extraArgs = {
|
|
|
|
|
happy = pkgs.haskellPackages.happy_1_19_2;
|
|
|
|
|
alex = pkgs.haskellPackages.alex_3_1_3;
|
|
|
|
|
};
|
2012-05-14 15:09:05 +02:00
|
|
|
};
|
2012-05-28 12:53:46 +02:00
|
|
|
|
2012-05-14 15:09:05 +02:00
|
|
|
}
|