Haskell: haskell.lib.composable init and switch

[expipiplus1]

Supersedes #100732

Basically, makes the drv argument to everything in haskell.lib the last argument. Some discussion in the above PR

[Gabriella439]

I think my main suggestion would be to split this into at least two pull requests:

• One pull request to introduce the composable versions of the functions
• Another pull request to switch existing uses over to the new version

[Profpatsch]

Also take into account lib.pipe, which makes code like this possible:

lib.pipe drv [
 hlib.doCheck
 (drv: hlib.removeConfigureFlag drv "flag")
 …
]

[Profpatsch]

This will make the nesting problem cause of the flipped arguments less problematic.

[maralorn]

I think that we all agree that this is the right way to go. The question is can we go in this direction and if so, how? Infinitely maintaining two versions of the library would be very unsatisfying.

[Profpatsch]

I don’t think it’s so big an annoyance that breaking all backwards compat is justified, and maybe not even big enough to split the ecosystem even further? I don’t see any good way to solve this initial misdesign now that so much code depends on it :(

[maralorn]

Well in a world where markUnbroken and unmarkBroken both already exist, I think there is room to argue that a few more functions won’t really hurt?

[expipiplus1]

I think my main suggestion would be to split this into at least two pull requests:

Done: #144705

This will make the nesting problem cause of the flipped arguments less problematic.

Was this referring to the use of lib.pipe to make using the current functions nicer, or the fact that this change itself solves the nasty nesting problem? I agree with both, but the neatest solution overall IMO is lib.pipe with these flipped functions.

[expipiplus1]

hahah, I just noticed that lib.pipe itself has the weird argument order where the element being transformed comes first...

edit, this is actually explained in the commit message for pipe:

`pipe` is a useful operator for creating pipelines of functions.

It works around the usual problem of e.g. string operations becoming
deeply nested functions.

In principle, there are four different ways this function could be
written:

pipe val [ f1 .. fn ]
pipe val [ fn .. f1 ]
compose [ f1 .. fn ] val
compose [ fn .. f1 ] val

The third and fourth form mirror composition of functions, they would
be the same as e.g. `(f1 << f2 << f3 .. << fn) val`.
However, it is not clear which direction the list should have (as one
can see in the second form, which is the most absurd.

In order not to confuse users, we decide for the most “intuitive”
form, which mirrors the way unix pipes work (thus the name `pipe`).
The flow of data goes from left to right.

[expipiplus1]

I don’t think it’s so big an annoyance that breaking all backwards compat is justified, and maybe not even big enough to split the ecosystem even further? I don’t see any good way to solve this initial misdesign now that so much code depends on it :(

well, the previous functions are still available under .lib. I definitely prefer the case of having both sets in nixpkgs than just the old ones. In terms of eventually removing and replacing the old set (i.e. having haskell.lib = haskell.lib.composable) maybe that's something we can tackle down the line, or just leave forever.

I suppose I was definitely aiming for replacing the old set when putting the deprecation warning in, but I'd be very happy to compromise that away.

[Profpatsch]

I’m okay with the change in general, but I have some changes I would like to see:

• don’t deprecate the old module functions
• call it .compose instead of composable (just less typing and same content)
• Define everything in compose in terms of the old definitions, don’t duplicate any implementation as it does right now (single source of truth).
• Maybe add some documentation to the non-compose module header and the nixpkgs haskell documentation that compose is preferred.

Other than that I’m looking forward to using these functions in the future.

[expipiplus1]

* don’t deprecate the old module functions

* call it `.compose` instead of `composable` (just less typing and same content)

* Maybe add some documentation to the non-compose module header and the nixpkgs haskell documentation that `compose` is preferred.

done done done, NixOS/cabal2nix#528

* Define everything in `compose` in terms of the old definitions, don’t duplicate any implementation as it does right now (single source of truth).

The old lib has always been defined in terms of compose, I hope this is OK.

Other than that I’m looking forward to using these functions in the future.

Me too!

[Profpatsch]

The old lib has always been defined in terms of compose, I hope this is OK.

Ah, I didn’t see that. It has the disadvantage that the history gets a bit mangled, but personally I don’t care which way around it is.

[Profpatsch]

The next step will be to update https://haskell4nix.readthedocs.io/ to use compose in all examples. But due to the fact that it’s not “in tune” with the rest of the manual, that can’t be done in this repository.

cc @sternenseemann