Remove unicode syntax from exposed APIs

[axman6]

Trying to make sense of the various operators used in the public API of this library is made a lot more difficult by the use of unicode syntax - a large component of programming is pattern matching and it's difficult to go through the mental process of realising that

(<*<) :: Applicative φ => φ (β -> γ) -> φ (α -> β) -> φ (α -> γ) 

is actually just

(<*<) :: Applicative f => f (b -> c) -> f (a -> b) -> f (a -> c) 

i.e., applicative function composition.

For a library that is most likely to see use in production code, there's no good reason to make the job of the user more difficult. I can read these types, my colleagues probably wouldn't be able to without quite a lot of effort, and there's no benefit to that effort.

[larskuhtz]

The module consistently uses greek letters for all type variables. I don't have a strong opinion about which alphabet should be preferred. Both, the greek and the latin alphabet are common and not too different. Personally I think, both versions above are equally readable.

I don't think it's worth touching so many code lines, just to change variable names.

[axman6]

It's not the alphabet that's the problem, it's that it obscures the types from the familiar patterns Haskell developers are used to, imposes a non-zero burden of translation on developers - particularly new developers - for no benefit whole being inconsistent with its own ecosystem (Applicative, optparse-applicative, aeson, lens, etc.). The changes are isomorphic, so would only need a 0.0.0.1 version increment. Using UnicodeSyntax is generally frowned upon in libraries, because of the above reasons.

I really like this library, it's helped solve a lot of problems for us, but it is already a library with a non-trivial interface, and obscuring the types just makes it harder to use.

[endgame]

Agree with @axman6. I write haskell to cut down on mental busywork, and alpha-converting type signatures in my head fits into that category.

Also, the applicative-composition functions would be handy in a standalone library, and that might be a change that's worth the number of LoCs touched.

(BTW, it is a good library and I thank you for writing it.)

[larskuhtz]

I don't really care about which alphabet is used for variable names. So, I am happy to accept a PR for changing all variable names to the latin alphabet. The PR should apply the change consistently across the package.

Note that the choice of variable symbols has nothing to do with UnicodeSyntax. Haskell generally uses the unicode character set [https://www.haskell.org/onlinereport/lexemes.html](). UnicodeSyntax enables the usage of certain unicode characters (e.g →, ∀) in place of some language keywords (e.g ->, forall).

[axman6]

Uh, good point, I'd forgotten that point. I'll submit a PR shortly.

[larskuhtz]

@endgame I agree, that the applicative function-composition operators seem useful beyond this package. At the time of writing the library I was actually surprised, that these weren't defined anywhere yet. Maybe they should be part of Data.Functor (<$<) and Control.Applicative (<*<)? But maybe they are not used commonly enough for being part of base?

I am happy to hear that you find the library useful. I currently have only limited time to spend on the library, and there are definitely some rough edges that could use some work and ideas. Feedback and code contributions are very welcome.

[endgame]

The PR was merged and appears to be released: http://hackage.haskell.org/package/configuration-tools-0.4.0/docs/Configuration-Utils-Operators.html

Should this be closed?