[Nix-dev] Haskell NG

Charles Strahan charles.c.strahan at gmail.com
Sun Dec 28 23:14:58 CET 2014


Peter,

Awesome work on Haskell-NG. How much work remains before we can flip the
switch?

-Charles

On Sun, Dec 28, 2014 at 3:53 PM, Charles Strahan <
charles.c.strahan at gmail.com> wrote:

>
> > I'm trying to think of a way of selling my oop library [...]
>
> What OOP library are you talking about? Is it available for me to view
> online?
>
> -Charles
>
> On Thu, Dec 18, 2014 at 12:38 PM, <roconnor at theorem.ca> wrote:
>
>> On Thu, 18 Dec 2014, Peter Simons wrote:
>>
>> > Hi Russel,
>> >
>> > >> 2) Haskell packages support 'deepOverride'.
>> > >
>> > > How would you feel about using my overrideScope functionality from my
>> > > haskellPackagesFixpoint branch instead?
>> >
>> > the first version of my re-factored Haskell code defined deep overrides
>> exactly
>> > the way you did it. Check out the "definePackage" function in [1].
>> You'll find
>> > that I studied your work thoroughly.
>> >
>> > My impressions are:
>> >
>> > 1. overrideScope and deepOverride achieve the same goal. I discovered
>> no case
>> >    where one function worked but the other one didn't.
>> >
>> > 2. deepOverride is a standard function every callPackage derivation
>> supports.
>> >    overrideScope, on the other hand, is not.
>> >
>> > 3. deepOverride is implemented in a simple generic algorithm (for
>> appropriate
>> >    definitions of the term "simple") that requires no special support
>> from the
>> >    haskellPackages record to function. overrideScope, on the other
>> hand, needs
>> >    the magic nixClass attribute (__unfix__ in my code) to build a stack
>> of
>> >    extension functions.
>> >
>> > Ultimately, I felt that I should stick to the standard deepOverride
>> mechanism
>> > mostly due to Occam's razor'ish reasoning: I'd rather not introduce a
>> new
>> > sophisticated tying-the-knot mechanism to haskellPackages just to do
>> the same
>> > thing that deepOverride can do already.
>> >
>> > Does that make sense?
>>
>> That is fair reasoning.
>>
>> I will add that I expect overrideScope to run exponentially faster than
>> deepOverride in worst case.  A similar change to replace-dependency took
>> the evaluation time for replacing bash in a NixOS system from 65 minutes
>> to instantaneous <https://githum.com/NixOS/nixpkgs/pull/4313>.  Replacing
>> bash in a NixOS system is probably *the* worst case scenario because bash
>> so deep in the dependency graph.  Until deepOverride starts taking
>> appreciable time, the efficencies of overrideScope is probably not yet a
>> pursuasive argument.
>>
>> So please keep an eye out for long evaluation times when using
>> deepOverride as you continue your work. :)  Haskell applications have
>> deeper and more fine grained dependencies than regular applications so
>> you might be more likely to run into evaluation time problems than others.
>>
>> What I really need to do is convince Eelco Dolstra and Michael Raskin that
>> semantics of overriding packages and semantics of object oriented
>> programmed coincide and they should adopt my oop library for implementing
>> the overriding mechanism.
>>
>> I'm trying to think of a way of selling my oop library to them that is a
>> little more light weight that flying to europe to give them a presenation.
>> Maybe I should use the Ocaml package set as a testbed to demonstrate
>> overrideScope.
>>
>> --
>> Russell O'Connor                                      <http://r6.ca/>
>> ``All talk about `theft,''' the general counsel of the American
>> Graphophone
>> Company wrote, ``is the merest claptrap, for there exists no property in
>> ideas musical, literary or artistic, except as defined by statute.''
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20141228/e3d55826/attachment.html 


More information about the nix-dev mailing list