Details on the dot

Records proposal requires the current Haskell function composition dot operator to have spaces on both sides. No spaces around the dot are reserved for name-spacing: this use and the current module namespace use. No space to the right would be partial application (see
​TDNR. The dot operator should bind as tightly as possible.

Summary

The community needs to deprecate the usage of dot for function composition, perhaps starting with requiring spaces around the function composition dot. We should move to a new ascii operator and a unicode dot operator.

Partial application

.x (no space after the dot), for any identifier x, is a postfix operator that binds more tightly than function application, so that parentheses are not usually required.

.a r == r.a

When there are multiple operators, they chain left to right

(r.a.b.c) == (.c $ .b $ .a r)

See below for how partial application can allow for different code styles.

Question: does this now hold?

r.a == r.(Record.a) == r.Record.a

Dealing with dot-heavy code

Identifying the difference between a name-space dot and function composition

Given the dot's expanded use here, plus its common use in custom operators, it is possible to end up with dot-heavy code.

quux (y . (foo>.< bar).baz (f . g)) moo

It's not that easy to distinguish from

quux (y . (foo>.< bar) . baz (f . g)) moo

What then is the future of the dot if this proposal is accepted? The community needs to consider ways to reduce the dot:

1) discourage the use of dot in custom operators: >.< could be discouraged, use a different character or none: ><
In most cases the dot in custom operators has little to no inherent meaning. Instead it is just the character available for custom operators that takes up the least real-estate. This makes it the best choice for implementing a custom operator modeled after an existing Haskell operator: .== or .< is normably preferable to @== and @<.

2) discourage the use of dot for function composition - use a different operator for that task. Indeed, Frege users have the choice between <~ or the proper unicode dot.
Haskell also has Control.Category.<<<

Discouraging the use of the dot in custom operators makes the example code only slightly better. With using a different operator we now have:

quux (y <~ (foo>.< bar).baz (f <~ g)) moo

Very easy to distinguish from

quux (y <~ (foo>.< bar) <~ baz (f <~ g)) moo

If you are disgusted by <~ than you can use the very pretty unicode dot. Or we can stick with the category operator <<< instead of <~: