# Section notation

I do not know the origins of section notation, or the terminology `section' (which I first heard used by Richard Bird). The notation is used for example in the programming language Haskell. It is a convenient and workable notation for the partial application of binary operators, which is `quieter' and clearer than the use of lambda abstraction.

Especially in connection with `point free' notation, its overuse can lead to impenetrable thickets of operators like: `((.(.)).)` (where `.' stands for the composition operator). (Point free notation is a calculation-oriented syntax favoured by Dutch computer scientists which contrives among other things to avoid explicit use of variable binding constructs.) If one is adept at carrying out formal manipulations reliably, unhindered by worrying about what the formulas mean, it is fine.

Sections are written as `(op)`, `( op e )`, or `( e op )`, where op is a binary operator and e is an expression.

For binary operator op and expression e, the section ```(op e)``` is equivalent to ` \ x -> x op e ` if ``` x ``` is a variable that does not occur free in e, and the section ` (e op) ` is equivalent to ``` (op) e ``` . I believe that ` (op e) ` is called a right section, and ` (e op) ` a left section.

There is an explanation of the notation in the Haskell report, here.

Another quite common convention with the same agenda of alleviating the burden of bound-variable notation sometimes uses an underline character as a blank to indicate `where the argument goes', as in `( _ op _ )`,`(_ op e)` and ```(e op _)```. This can be clear, but it seems noisier than it needs to be. (One can use simply a small amound of space for the blank, but it isn't loud enough.) Furthermore, it useful to use the underline character (again, as in Haskell) as a special identifier which may only occur in binding position, to make it clear that the variable named by the identifier has no occurrences in the scope of the binding construct.

There are some old notes related to this, concerning `split' operators.

Peter Hancock