Monad

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.

You probably have already read things like “Async computations form a Monad” or something like that. Did you ever ask yourself why would they? Here are the answers for you. Have you ever seen that kind of device in some chemical and physics labs – a glass wall, with two holes in it which have a pair of thick gloves attached to them, to reach inside? A person put his hands into these gloves and reach into a contained and sealed compartment (environment) and is able to perform some tasks, like moving and filling things inside. ...