Nested newtype wrapper vs Stream/StreamK Applicative and Monad instances

[harendra-kumar]

Do we want MonadState, MonadReader etc instances in future for this type? If so we will need to depend on mtl - streamly-core currently does not depend on mtl. Or we will have to move these types to streamly instead of streamly-core.

Another option is - instead of using newtype wrappers we can merge these instances with the Stream and StreamK types. We can use the concatFor (bind) operations directly instead of Monad instance, but a Monad instance could be useful where it is used implicitly - e.g. MonadComprehensions. We did not add a Monad instance earlier to avoid the misuse of the monad instance. What are the potential misuses?

• We must not have Semigroup and MonadPlus instances for Stream type so it cannot be appended, append has quadratic complexity for Stream, though we can have it for StreamK which has a linear append.
• Left associating the binds in a chain could hurt performance - they should be explicitly right associated
• Applicative should be preferred as it would be much faster - maybe we can just provide an Applicative and leave the monad type composition to explicit concatFor (bind) operations.