Hacker News Reader

Comment by munchler | Hacker News Reader

That would be nice, but refactoring canonical F# is still far easier than C# due to its referential transparency.

https://dev.to/ruizb/function-purity-and-referential-transpa...

No, it is not. Referential transparency <<< tooling.

Plus F# as a functional language has significant gaps that prevent effective refactoring, such as lack of support for named arguments to curried functions.

Can you give me an example where lack of support for named arguments to curried functions makes refactoring difficult? I'm having trouble understanding how that would happen.

For one there's no way to add a curried parameter without doThing4-style naming and lack of named arguments implies you can't have a default value for the new parameter.

Another one is if you want to add a curried parameter to the end of the parameter list, and you have code like

  |> myFunc a b
  |> ...

You can't just say

  |> myFunc a b z=10
  |> ...

instead, you have to rewrite the whole pipe.

OK, I think I see what you mean. I certainly agree that named arguments with default values can be useful, but are not supported by curried functions.

Reply on news.ycombinator.com