NoImplicitFunctionCurrying

[GabrielBoehme13]

What the rule should do:

Whenever a function is called, require all of its arguments to be specified.

In situations where currying is needed, the user will need to express that explicitly.

What problems does it solve:

• Code Understandability: I've discovered that past Elm code I've written using implicit currying is more difficult for me to understand later. My experience mirrors something Richard Feldman mentioned in one of his talks, about how Elm's implicit function currying is one of the more difficult concepts for Elm newcomers to learn.
• Performance Impacts: From reading about Elm's built-in function currying (including elm-optimize-level-2 articles and recent discussion on the NoEtaReducibleLambdas rule), it sounds like explicit function currying would have performance benefits over Elm's built-in implicit currying.
• Explicit vs. Implicit: Elm very much favors explicit code, so this would fit in with the overall spirit of the language and its libraries.
• Is Implicit Currying Really Needed? As mentioned in "A Taste of Roc", Richard Feldman's Elm-inspired functional programming language Roc isn't going to have function currying. This got me thinking, do functional programming languages really require implicit function currying? What would Elm code look like without it?

Examples of things the rule would report:

add : number -> number -> number
add x y =
    x + y

-- disallowed – the last argument for `add` is implicit
addFive : number -> number
addFive =
    add 5

-- disallowed – the last arguments for `add` and `List.map` are implicit
addTenToList : List number -> List number
addTenToList =
    List.map (add 10)

Examples of things the rule would not report:

add : number -> number -> number
add x y =
    x + y

-- allowed – all arguments for `add` are explicitly specified
addFive : number -> number
addFive n =
    add 5 n

-- allowed – all arguments for `add` and `List.map` are explicitly specified
addTenToList : List number -> List number
addTenToList list =
    List.map (\n -> add 10 n) list

When (not) to enable this rule:

If you come from a Haskell or ML language background, or are just generally comfortable with a point-free coding style, then this rule likely isn't for you.

If you come from a more traditional programming language background, or want to ensure that code written today will still be clearly understandable in future, then this may be the rule for you.

I am looking for:

• Feedback
  • Would others find this rule helpful?
  • Is there a better name for it?
• Someone to implement this rule

[wolfadex]

Before reading past the title I was immediately reminded of Richard Feldman talking about this being one of the more challenging topics when teaching Elm.

Would I find this helpful?

I find myself on both sides of this. I'm very comfortable with currying, which is funny because I learned it mostly from Elm, but I'm fine with never using it. I don't know how difficult this would be to implement but there's a decent chance I'd start using it once completed.

Is there a better name for it?

I think this name is perfectly fine.

Someone to implement this rule

I don't think I'm interested in implementing, but I'll keep my eye this discussion.

[lydell]

NoImplicitFunctionCurrying

What would an example of explicit function currying be?

In situations where currying is needed, the user will need to express that explicitly.

Do you have an example on how to express that?

---

Possibly in other words, what are the differences to a hypothetical NoCurrying rule?

[GabrielBoehme13]

NoImplicitFunctionCurrying

What would an example of explicit function currying be?

In situations where currying is needed, the user will need to express that explicitly.

Do you have an example on how to express that?

When I was thinking of implicit vs. explicit currying, this is the distinction I was making in my mind:

-- implicit currying -- arguments can be specified all at once, or one at a time, or anything in between
-- the user has to understand this – you can't tell from the function definition how it's expected to be called
-- [if this rule were implemented, this function could only be called with exactly three arguments specified]
exampleOne arg1 arg2 arg3 =
    {- function body here -}

-- explicit currying -- we expect to call this function one argument at a time
-- [if this rule were implemented, each function shown could only be called with exactly one argument specified]
exampleTwo arg1 =
    \arg2 ->
        \arg3 ->
            {- function body here -}

-- explicit currying with argument groupings
-- [if this rule were implemented, the initial function could only be called with exactly one argument, 
-- while the returned function could only be called with exactly two arguments]
exampleThree arg1 =
    \arg2 arg3->
        {- function body here -}

Possibly in other words, what are the differences to a hypothetical NoCurrying rule?

This is a fair point – perhaps my proposed name is unnecessarily specific, and the simpler name "NoCurrying" is sufficient?