It is time to publish some more results.

```
Type-level reasoning
A function application - corresponds to /Modus Ponens/
A specialization, an instance of it.
> ($) :: (a -> b) -> a -> b
> ($) f x = f x
Reversed order of agreements, still the same /Modus Ponens/
> (|>) :: a -> (a -> b) -> b
> (|>) x f = f x
"Multi-argument" is just /currying/ -- ~* ->*->*-> *~
Same, but with an explicit /abstraction barrier/ (and /lifting/)
> (>>=) :: m a -> (a -> m b) -> m b
> (>>=) ma f = undefined -- has to be defined for each particular type (an instance)
Notice that this is essentially a type-signature of ~fmap~,
> fmap :: f a ->(a->b) -> f b
with a reversed order of arguments and a specialized function.
which corresponds to a /Kleisli arrow/.
Notice also that ~($)~ and ~fmap~ differs only in having an explicit /container/.
This is not an arbitrary coincidence.
All three are essentially the same, despite funny syntax.
A basic step of logical deduction. Behind an abstraction barrier.
Composition
- of functions
> (.) :: (b -> c) -> (a -> b) -> a -> c
> (.) f g = \x -> f (g x)
- of "actions" (actual functions have to use ~return :: a -> m a~)
> (<=<) :: Monad m => (b -> m c) -> (a -> m b) -> a -> m c
> (<=<) f g = undefined -- has to be defined for each particular type
or ~(>>=)~ for chaining ("flat" nesting or pipelining ) , exactly the same as ~(|>)~
Notice that the composition is /nesting/. This is the /only/ way to implement it.
The end of knowledge.
```