Monad has the following components.

1. a and m a which converted from a by a Functor
2. a -> m b arrow and a way to change m m to m
3. composition of arrows

If there is a structure that has 1,2 regardless of composition, can I say it's Monadic?

Sure, If a structure has 1 and 2, It can be composed. but It doesn't have to be concerned or not?

edited:

I thought that associativity, Identity are about composition. If a structure has all exactly, It's just a Monad. My Question is about "Monadic". the most important factor of Monad is mu(join), so if a structure has only mu, Could it be a Monadic thing roughly ?

or Monadic is just an adjective for Monad.
"Monadic" thing means that It's a factor of a Monad.
Monadic structure of a Monad
Monadic type m a of a Monad,
Monadic arrow a -> m b of a Monad,
Monadic compostion >=> of a Monad
...

CodePudding user response：

This looks like two questions: a question about terminology, and a question about whether the monad laws relate to "composition" only.

For the terminology question...

As pointed out by @cstml in a comment, there's a formal definition of a "monadic functor" in category theory, but I don't think Haskell programmers typically use "monadic" in this formal sense, and it doesn't look like you're asking about that.

When I use the term "monadic", I typically use it in the sense of "things pertaining to a monad". So a monadic action is an expression of the form m a for a Monad m and when I engage in monadic programming, I'm using monads.

I don't typically use it in the sense of "monad-like", but I could see maybe saying something like "arrows have some monadic behavior, but they aren't necessarily monads". On the other hand, if you say "type X is monadic" without qualification, that sounds like just an unusual way of saying "type X is a monad".

For the monad laws question...

Even though the monad laws for Haskell are usually expressed in terms of return and >>=, an alternative set of laws that only involve return, fmap, and join can be formulated. That is, the join operator all by itself satisfies identity and associativity laws that are more or less equivalent to the laws satisfied by >>=.

Specifically, any monad obeys the obvious laws:

fmap f . return = return . f
join . fmap return = id
join . return = id

If you have an object that supports operations:

return :: a -> m a       -- convert from `a` by functor
join :: m (m a) -> m a   -- change `m m` to `m`

but doesn't satisfy any of these laws, then it doesn't seem very "monadic".

If it does satisfy the above laws, then the composition defined by:

x >>= f = join (fmap f x)

will automatically satisfy the usual Haskell left and right identity laws:

return a >>= k = k a
m >>= return = m

so these laws aren't "just about composition".

The only usual Haskell law not implied by the above is associativity. Like the others, it can be expressed in terms of join and fmap instead of >>= and it takes the form:

join . fmap h . join . fmap k = join . fmap (join . fmap h . k)

Basically, the question of associativity can either be expressed as the associativity of the composition of monad arrows or as the associativity of the join operation acting on the type m m m a -- in other words, does it matter if you join the outer layer first or the inner layer first?