Above, I suggested redefining inO to “say what I mean plainly: inO applies unO to the argument and O to the result.”

inO = result O . argument unO

Matt’s idea is to package up this pattern of use of result and argument and give it a name. And not just any name, but an infix operator that looks like an arrow and is right-associative, to mimic the notation of function types.

infixr 2 ~>
f ~> g = argument f . result g

Now inO, inO2, etc have lovely, simple definitions:

inO  = unO ~> O
inO2 = unO ~> inO
inO3 = unO ~> inO2
-- ...

Written out,

inO3 = unO ~> unO ~> unO ~> O

which can be read as saying that the semantic editor combinator inO3 passes three arguments through unO before invoking a given editor and then the editor’s result through O.

This notational technique can be used in many other ways besides stripping and restoring newtype constructors. Matt’s examples include use of id when arguments and/or results do not need transforming.

Afterthought: SECs built up with (~>) (or explicitly with result and argument) remind me vaguely of method combination in some object systems, like CLOS, but in a functional style — where after and before methods combine with inherited methods via function composition rather than sequential execution. Even this apparent difference diminishes if one considers a standard denotational semantics of sequential execution as function composition. For instance, a denotational semantics for method combination might be written elegantly in terms of argument, result, and (~>).