Add the compose function.

[tibastral]

The compose function is useful when we want to apply a chain of functions to a single argument.

[jvoigtlaender]

My take:

This should be in a functions-extra or similar package, not in list-extra. Elm encourages use of qualified function names. And it seems just wrong to me to read List.compose and mean this function as implemented here (in contrast to, for example, List.reverse, which makes perfect sense as a full name).

It would read much better if this function's fully qualified name would read Function.composed or Functions.compose or similar. Hence, in a functions-extra package (which does not yet exist, but could be created).

[jvoigtlaender]

Alternatively, find some other name (than compose), so that the fully qualified name List.theName makes sense and gives some indication of what the function does. I think, List.compose does not. We are composing a list? From what? From individual lists? So is this function, List.compose, something like List.foldl [] (++)?

[tibastral]

We are composing a list of functions together. It is really great to be able to have that. Saying that it should be in a Function package make the same sense as putting the sum function inside the Number package.

[jvoigtlaender]

The thing is that neither "list" nor "compose" invokes any specific association with "function". There are many things that can be "composed", not just functions.

So, it is true that you "are composing a list of functions" together, but while "composing" and "list" are represented in the name List.compose, the crucial ingredient "functions" is not. That's the problem I see.

Also, I am not sure what to make of this argument:

Saying that it should be in a Function package make the same sense as putting the sum function inside the Number package.

Is this supposed to be an argument against putting your function into a Function package? I don't see the analogy. Actually, the real analogy I see is: "Putting this [the function from this pull request] into List is like putting an (uncurried) function (+) : (Int, Int) -> Int into Tuple, as Tuple.sum, given that it takes the sum of the components of a tuple (without telling us that it's Ints which are summed up)".

Tuple.sum : (Int, Int) -> Int
List.compose : List (a -> a) -> (a -> a)

These two are exactly equally justified. I think positioning the first of those as Tuple.sum would be a bad idea. (Do you agree?) Positioning the second of those as List.compose is then an equally bad idea.

[tibastral]

Thank you for your answer !

I was talking about List.sum which is in the List package.

What about renaming it List.composeFunctions for more clarity ?

[jvoigtlaender]

I don't really know what you mean by you were talking about List.sum. When?

In any case, the situation with List.sum is not analogous to the hypothetical Tuple.sum I brought up. The reason is that List.sum (in core) is typed as List number -> number. If it were typed as List Int -> Int, then the name List.sum would be equally inappropriate as the name Tuple.sum is for (Int, Int) -> Int (which is what I compared List.compose : List (a -> a) -> (a -> a) to).

Any yes, I think List.composeFunctions would be clearer. I still like something like Functions.compose better, but List.composeFunctions does address the point I was making above.

[ghivert]

👍 for the PR

[Chadtech]

@tibastral , could you elaborate on the use case where you would wantcomposeFunctions? I can recall a few of my own instances where I have done similar things, but, not any that I think would have better with a composeFunctions.

I also think the same way as @jvoigtlaender on whether this belongs in List.Extra. composeFunctions doesnt make working with lists generally easier, rather, it uses a list in a neat way. But I can see that maybe that distinction might be weak.

[Chadtech]

If there arent any developments on this PR in the near future, I will close it.