This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Nested monads

12 replies
Ka Ter
Joined: 2011-10-05,
User offline. Last seen 42 years 45 weeks ago.
Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter


Derek Williams 3
Joined: 2011-08-12,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads

That would be a "monad tramsformer" if I'm not mistaken:

http://en.wikipedia.org/wiki/Monad_transformer

Scalaz contains a few examples, I believe anything ending in 'T' indicates a monad transformer.

Derek Williams

On Oct 7, 2011 7:29 AM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com> wrote:
Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter


Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Nested monads
Exactly.  A Monad Transformer MT[_] creates a new monad from an existing monad:   MT[Option] or MT[List] would both be Monads.
Not all monads are Monad transformers, but enough are as to allow a strange form of composition.
- Josh

On Fri, Oct 7, 2011 at 9:50 AM, Derek Williams <derek [at] fyrie [dot] net> wrote:

That would be a "monad tramsformer" if I'm not mistaken:

http://en.wikipedia.org/wiki/Monad_transformer

Scalaz contains a few examples, I believe anything ending in 'T' indicates a monad transformer.

Derek Williams

On Oct 7, 2011 7:29 AM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com> wrote:
Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter



Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Nested monads


On Fri, Oct 7, 2011 at 5:56 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Exactly.  A Monad Transformer MT[_] creates a new monad from an existing monad:   MT[Option] or MT[List] would both be Monads.
Not all monads are Monad transformers, but enough are as to allow a strange form of composition.

Not all Transformers are Monads. Optimus Prime for example.
 

- Josh

On Fri, Oct 7, 2011 at 9:50 AM, Derek Williams <derek [at] fyrie [dot] net> wrote:

That would be a "monad tramsformer" if I'm not mistaken:

http://en.wikipedia.org/wiki/Monad_transformer

Scalaz contains a few examples, I believe anything ending in 'T' indicates a monad transformer.

Derek Williams

On Oct 7, 2011 7:29 AM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com> wrote:
Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter






--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: Nested monads
I think that's one for my recently suggested "scala-questionably-related-tangets" mailing list
:)



2011/10/7 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Fri, Oct 7, 2011 at 5:56 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Exactly.  A Monad Transformer MT[_] creates a new monad from an existing monad:   MT[Option] or MT[List] would both be Monads.
Not all monads are Monad transformers, but enough are as to allow a strange form of composition.

Not all Transformers are Monads. Optimus Prime for example.
 

- Josh

On Fri, Oct 7, 2011 at 9:50 AM, Derek Williams <derek [at] fyrie [dot] net> wrote:

That would be a "monad tramsformer" if I'm not mistaken:

http://en.wikipedia.org/wiki/Monad_transformer

Scalaz contains a few examples, I believe anything ending in 'T' indicates a monad transformer.

Derek Williams

On Oct 7, 2011 7:29 AM, "Ka Ter" <ter [dot] ka966 [at] googlemail [dot] com> wrote:
Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter





Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Nested monads

2011/10/7 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>


On Fri, Oct 7, 2011 at 5:56 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Exactly.  A Monad Transformer MT[_] creates a new monad from an existing monad:   MT[Option] or MT[List] would both be Monads.
Not all monads are Monad transformers, but enough are as to allow a strange form of composition.

Not all Transformers are Monads. Optimus Prime for example.


How can you say that?   Optimus Prime can really flatMap the Decepticons.
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads
Dear Ka,
First of all i want to acknowledge the acuity of your question. A great deal depends on how natural, effective and intuitive the composition of monads is. The composition of monads -- what you call nesting --  is not always guaranteed (by the monad laws) to be a monad. 
A monad transformer is one approach to structuring monad composition. However, let me put in a plug for another: distributive laws. A distributive law is a map from the type constructor underlying one monad to the type constructor underlying the other satisfying certain additional constraints.
i'm on my iPhone, so i'll defer more technical exegesis until i can type at a reasonable speed. Let me just stress that the question you have asked is at the heart of the larger question of whether monads can provide a more rational notion of object than object. The critique of OO has been that the composition mechanism don't -- in practice -- support real reuse. If there's another proposal on the table, one of our first concerns should be whether that proposal comes with any better support for composition -- one that supports effective reuse in practice. So, your question has significantly raised the level of the conversation.
Best wishes,
--greg

Managing PartnerBiosimilarity LLC
On Oct 7, 2011, at 6:29, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com> wrote:

Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter


Ka Ter
Joined: 2011-10-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads
Thanks for your thoughts. I'm now reading what monad transformers are in order to decide if this is the missing concept.
Monads are a heavy stuff since it is based both on mathematical concepts and on concepts of computer science in order to make monads more applicable to functional programs. Well, although I nearly know what I need in the end, I cannot describe the concept using the appropriate terms. Now I have an additional term: monad transformer.

Cool would be a monad transformer that could wrap a Scala collection without hiding the interface of the wrapped collection. The monad then could automatically perform it's internal task whenever one of the collection's method is used. I thought about that a lot. Since almost every method of a Scala collection class is based on foreach or at least uses one of the typical monad methods (map, flatMap, etc.) it would be sufficient if the monad only affects these methods.
Perhaps a solution could also be, to implement all of the methods of a Traversable but then the type of the wrapped collection would be generalized to a Traversable.

But this sounds very very crazy and I cannot even say if it is possible or if it is even necessary.

Best Regards

Ka Ter

Am 07.10.2011 20:02, schrieb Meredith Gregory:
EA0B681C-23C1-4E55-B9F0-7B193F1BE1F7 [at] gmail [dot] com" type="cite"> Dear Ka,
First of all i want to acknowledge the acuity of your question. A great deal depends on how natural, effective and intuitive the composition of monads is. The composition of monads -- what you call nesting --  is not always guaranteed (by the monad laws) to be a monad. 
A monad transformer is one approach to structuring monad composition. However, let me put in a plug for another: distributive laws. A distributive law is a map from the type constructor underlying one monad to the type constructor underlying the other satisfying certain additional constraints.
i'm on my iPhone, so i'll defer more technical exegesis until i can type at a reasonable speed. Let me just stress that the question you have asked is at the heart of the larger question of whether monads can provide a more rational notion of object than object. The critique of OO has been that the composition mechanism don't -- in practice -- support real reuse. If there's another proposal on the table, one of our first concerns should be whether that proposal comes with any better support for composition -- one that supports effective reuse in practice. So, your question has significantly raised the level of the conversation.
Best wishes,
--greg

Managing Partner Biosimilarity LLC
On Oct 7, 2011, at 6:29, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com" rel="nofollow">ter [dot] ka966 [at] googlemail [dot] com> wrote:

Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter


Jason Zaugg
Joined: 2009-05-18,
User offline. Last seen 38 weeks 5 days ago.
Re: Nested monads

On Fri, Oct 7, 2011 at 9:20 PM, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com> wrote:
Thanks for your thoughts. I'm now reading what monad transformers are in order to decide if this is the missing concept.

Here's a nice intro to the topic presented in Scala:
 http://debasishg.blogspot.com/2011/07/monad-transformers-in-scala.html
In contrast to Monads that don't compose (in general), Functors, and even Applicative Functors, do.
  http://etorreborre.blogspot.com/2011/06/essence-of-iterator-pattern.html
-jason 
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads
Dear Ka,
Suppose that we have
trait Functor[M[_]] {    def fmap [A,B] ( f : A => B ) : M[A] => M[B]}
trait Monad[M[_]] extends Functor {    def unit [A] ( a : A ) : M[A]   def mult [A] ( mma : M[M[A]]  ) : M[A]}
as before. Further suppose that we have two type constructors, S, T and witnesses to monadic views of these
class MonadS extends Monad[S] {   override def unit [A] ( a : A ) : S[A] = { ... }    override def mult [A] ( ssa : S[S[A]]  ) : S[A] = { ... } }
class MonadT extends Monad[T] {    override def unit [A] ( a : A ) : T[A] = { ... }    override def mult [A] ( tta : T[T[A]]  ) : T[A] = { ... } }
Then we might code a distributive law as something like
trait DistributiveLaw[S[_],T[_],MS <: MonadS, MT <: MonadT] {   ...   def distribute [A] ( sta : S[T[A]] ) : T[S[A]] }
The constraints that constitute the other data defining a distributive law will have to be verified -- like the monad laws -- by the programmer for each instance. 
Now, as Eugenia Cheng has shown, if you have two such laws and three monads, S, T, and U, then if you have a hexagonal condition (page 3 of the reference) governing the laws, you will be guaranteed that the composition, STU, (i.e. for type A, S[T[U[A]]]) is a monad and uniquely determined. Moreover, this solution iterates. Further, we see that this architecture smoothly extends to other combinations, comonad/comonad and monad/comonad and gives rise to expected and familiar structures. i believe that this evidence makes the distributive law the preferred choice over the monad transformer. However, a lot more work needs to be done to verify this position.
As mentioned on another thread, i suspect it is unwise to ignore the developments that are theoretically and mathematically satisfying as not being "real." It would be wise to remember that the notion of monad, itself, was discovered by mathematicians over 40 years ago.
Best wishes,
--greg

On Fri, Oct 7, 2011 at 11:02 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
Dear Ka,
First of all i want to acknowledge the acuity of your question. A great deal depends on how natural, effective and intuitive the composition of monads is. The composition of monads -- what you call nesting --  is not always guaranteed (by the monad laws) to be a monad. 
A monad transformer is one approach to structuring monad composition. However, let me put in a plug for another: distributive laws. A distributive law is a map from the type constructor underlying one monad to the type constructor underlying the other satisfying certain additional constraints.
i'm on my iPhone, so i'll defer more technical exegesis until i can type at a reasonable speed. Let me just stress that the question you have asked is at the heart of the larger question of whether monads can provide a more rational notion of object than object. The critique of OO has been that the composition mechanism don't -- in practice -- support real reuse. If there's another proposal on the table, one of our first concerns should be whether that proposal comes with any better support for composition -- one that supports effective reuse in practice. So, your question has significantly raised the level of the conversation.
Best wishes,
--greg

Managing PartnerBiosimilarity LLC
On Oct 7, 2011, at 6:29, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com> wrote:

Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads
P.S. It would be wise to remember that the notion of monad, itself, was discovered by mathematicians over 40 years ago. Hence, they have the most experience coding with the d*mned things.

On Fri, Oct 7, 2011 at 4:51 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
Dear Ka,
Suppose that we have
trait Functor[M[_]] {    def fmap [A,B] ( f : A => B ) : M[A] => M[B]}
trait Monad[M[_]] extends Functor {    def unit [A] ( a : A ) : M[A]   def mult [A] ( mma : M[M[A]]  ) : M[A]}
as before. Further suppose that we have two type constructors, S, T and witnesses to monadic views of these
class MonadS extends Monad[S] {   override def unit [A] ( a : A ) : S[A] = { ... }    override def mult [A] ( ssa : S[S[A]]  ) : S[A] = { ... } }
class MonadT extends Monad[T] {    override def unit [A] ( a : A ) : T[A] = { ... }    override def mult [A] ( tta : T[T[A]]  ) : T[A] = { ... } }
Then we might code a distributive law as something like
trait DistributiveLaw[S[_],T[_],MS <: MonadS, MT <: MonadT] {   ...   def distribute [A] ( sta : S[T[A]] ) : T[S[A]] }
The constraints that constitute the other data defining a distributive law will have to be verified -- like the monad laws -- by the programmer for each instance. 
Now, as Eugenia Cheng has shown, if you have two such laws and three monads, S, T, and U, then if you have a hexagonal condition (page 3 of the reference) governing the laws, you will be guaranteed that the composition, STU, (i.e. for type A, S[T[U[A]]]) is a monad and uniquely determined. Moreover, this solution iterates. Further, we see that this architecture smoothly extends to other combinations, comonad/comonad and monad/comonad and gives rise to expected and familiar structures. i believe that this evidence makes the distributive law the preferred choice over the monad transformer. However, a lot more work needs to be done to verify this position.
As mentioned on another thread, i suspect it is unwise to ignore the developments that are theoretically and mathematically satisfying as not being "real." It would be wise to remember that the notion of monad, itself, was discovered by mathematicians over 40 years ago.
Best wishes,
--greg

On Fri, Oct 7, 2011 at 11:02 AM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com> wrote:
Dear Ka,
First of all i want to acknowledge the acuity of your question. A great deal depends on how natural, effective and intuitive the composition of monads is. The composition of monads -- what you call nesting --  is not always guaranteed (by the monad laws) to be a monad. 
A monad transformer is one approach to structuring monad composition. However, let me put in a plug for another: distributive laws. A distributive law is a map from the type constructor underlying one monad to the type constructor underlying the other satisfying certain additional constraints.
i'm on my iPhone, so i'll defer more technical exegesis until i can type at a reasonable speed. Let me just stress that the question you have asked is at the heart of the larger question of whether monads can provide a more rational notion of object than object. The critique of OO has been that the composition mechanism don't -- in practice -- support real reuse. If there's another proposal on the table, one of our first concerns should be whether that proposal comes with any better support for composition -- one that supports effective reuse in practice. So, your question has significantly raised the level of the conversation.
Best wishes,
--greg

Managing PartnerBiosimilarity LLC
On Oct 7, 2011, at 6:29, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com> wrote:

Hi,

I have a beginner question concerning monads. How would you call a concept where monads
are nested but are used in a transparent way by users?

Assume you have a monad M[A]. Then the method 'bind' uses the type A and
produces another type M[B]. When I now have another monad G which wraps
the first one, I now have a G[M[A]]. Now G's bind method refers not to A
but to M[A]. So in case when you have several levels of nesting, for the
user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
because they also have to be called in a nested way.

Is there already a concept saying that when having nested monads, there
is some kind of special bind method that only refers to the inner monad?

In my case I want to work with collections and wrap it by one or more
monads.

val b: M[List[A]] = ....

in class M:
  def map(f: A => B): M[List[B]] = .....

or val g: G[M[A]] = .....

in class G
   def map(f: A => B): G[M[B]]

These monads add side-effects (e.g. automatically filter the result
sets; without changing the result type) and should be transparent which
means the user should work with it as if it is only a collection (of
course the collection's interface is overlapped by the one of the monad).

Is there already a concept for that defined and available?

-- 
Best Regards

Ka Ter





--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com
Alec Zorab
Joined: 2010-05-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads

Greg,

Every time I read one of your mails or posts, I find myself
simultaneously bemused and enlightened, which has, inevitably, left me
with a question festering in the back of my mind for some weeks now:

When's the book out?

Regards
Alec

On Sat, Oct 8, 2011 at 12:52 AM, Meredith Gregory
wrote:
> P.S. It would be wise to remember that the notion of monad, itself, was
> discovered by mathematicians over 40 years ago. Hence, they have the most
> experience coding with the d*mned things.
>
> On Fri, Oct 7, 2011 at 4:51 PM, Meredith Gregory
> wrote:
>>
>> Dear Ka,
>> Suppose that we have
>> trait Functor[M[_]] {
>>    def fmap [A,B] ( f : A => B ) : M[A] => M[B]
>> }
>> trait Monad[M[_]] extends Functor {
>>    def unit [A] ( a : A ) : M[A]
>>    def mult [A] ( mma : M[M[A]]  ) : M[A]
>> }
>> as before. Further suppose that we have two type constructors, S, T and
>> witnesses to monadic views of these
>> class MonadS extends Monad[S] {
>>    override def unit [A] ( a : A ) : S[A] = { ... }
>>    override def mult [A] ( ssa : S[S[A]]  ) : S[A] = { ... }
>> }
>> class MonadT extends Monad[T] {
>>    override def unit [A] ( a : A ) : T[A] = { ... }
>>    override def mult [A] ( tta : T[T[A]]  ) : T[A] = { ... }
>> }
>> Then we might code a distributive law as something like
>> trait DistributiveLaw[S[_],T[_],MS <: MonadS, MT <: MonadT] {
>>    ...
>>    def distribute [A] ( sta : S[T[A]] ) : T[S[A]]
>> }
>> The constraints that constitute the other data defining a distributive law
>> will have to be verified -- like the monad laws -- by the programmer for
>> each instance.
>> Now, as Eugenia Cheng has shown, if you have two such laws and three
>> monads, S, T, and U, then if you have a hexagonal condition (page 3 of the
>> reference) governing the laws, you will be guaranteed that the composition,
>> STU, (i.e. for type A, S[T[U[A]]]) is a monad and uniquely determined.
>> Moreover, this solution iterates. Further, we see that this architecture
>> smoothly extends to other combinations, comonad/comonad and monad/comonad
>> and gives rise to expected and familiar structures. i believe that this
>> evidence makes the distributive law the preferred choice over the monad
>> transformer. However, a lot more work needs to be done to verify this
>> position.
>> As mentioned on another thread, i suspect it is unwise to ignore the
>> developments that are theoretically and mathematically satisfying as not
>> being "real." It would be wise to remember that the notion of monad, itself,
>> was discovered by mathematicians over 40 years ago.
>> Best wishes,
>> --greg
>>
>> On Fri, Oct 7, 2011 at 11:02 AM, Meredith Gregory
>> wrote:
>>>
>>> Dear Ka,
>>> First of all i want to acknowledge the acuity of your question. A great
>>> deal depends on how natural, effective and intuitive the composition of
>>> monads is. The composition of monads -- what you call nesting --  is not
>>> always guaranteed (by the monad laws) to be a monad.
>>> A monad transformer is one approach to structuring monad composition.
>>> However, let me put in a plug for another: distributive laws. A distributive
>>> law is a map from the type constructor underlying one monad to the type
>>> constructor underlying the other satisfying certain additional constraints.
>>> i'm on my iPhone, so i'll defer more technical exegesis until i can type
>>> at a reasonable speed. Let me just stress that the question you have asked
>>> is at the heart of the larger question of whether monads can provide a more
>>> rational notion of object than object. The critique of OO has been that the
>>> composition mechanism don't -- in practice -- support real reuse. If there's
>>> another proposal on the table, one of our first concerns should be whether
>>> that proposal comes with any better support for composition -- one that
>>> supports effective reuse in practice. So, your question has significantly
>>> raised the level of the conversation.
>>> Best wishes,
>>> --greg
>>>
>>> Managing Partner
>>> Biosimilarity LLC
>>> On Oct 7, 2011, at 6:29, Ka Ter wrote:
>>>
>>> Hi,
>>>
>>> I have a beginner question concerning monads. How would you call a
>>> concept where monads
>>> are nested but are used in a transparent way by users?
>>>
>>> Assume you have a monad M[A]. Then the method 'bind' uses the type A and
>>> produces another type M[B]. When I now have another monad G which wraps
>>> the first one, I now have a G[M[A]]. Now G's bind method refers not to A
>>> but to M[A]. So in case when you have several levels of nesting, for the
>>> user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
>>> because they also have to be called in a nested way.
>>>
>>> Is there already a concept saying that when having nested monads, there
>>> is some kind of special bind method that only refers to the inner monad?
>>>
>>> In my case I want to work with collections and wrap it by one or more
>>> monads.
>>>
>>> val b: M[List[A]] = ....
>>>
>>> in class M:
>>> def map(f: A => B): M[List[B]] = .....
>>>
>>> or val g: G[M[A]] = .....
>>>
>>> in class G
>>> def map(f: A => B): G[M[B]]
>>>
>>> These monads add side-effects (e.g. automatically filter the result
>>> sets; without changing the result type) and should be transparent which
>>> means the user should work with it as if it is only a collection (of
>>> course the collection's interface is overlapped by the one of the monad).
>>>
>>> Is there already a concept for that defined and available?
>>>
>>> --
>>> Best Regards
>>>
>>> Ka Ter
>>>
>>>
>>
>>
>>
>> --
>> L.G. Meredith
>> Managing Partner
>> Biosimilarity LLC
>> 7329 39th Ave SW
>> Seattle, WA 98136
>>
>> +1 206.650.3740
>>
>> http://biosimilarity.blogspot.com
>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 7329 39th Ave SW
> Seattle, WA 98136
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>

Meredith Gregory
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Nested monads
Dear Alec,
Thanks for the inquiry! As Bill Venners mentioned, the EAP should be out by end of year, the book early next year. Check his email to the list for details.
Best wishes,
--greg

On Fri, Oct 7, 2011 at 5:27 PM, Alec Zorab <aleczorab [at] googlemail [dot] com> wrote:
Greg,

Every time I read one of your mails or posts, I find myself
simultaneously bemused and enlightened, which has, inevitably, left me
with a question festering in the back of my mind for some weeks now:

When's the book out?

Regards
Alec

On Sat, Oct 8, 2011 at 12:52 AM, Meredith Gregory
<lgreg [dot] meredith [at] gmail [dot] com> wrote:
> P.S. It would be wise to remember that the notion of monad, itself, was
> discovered by mathematicians over 40 years ago. Hence, they have the most
> experience coding with the d*mned things.
>
> On Fri, Oct 7, 2011 at 4:51 PM, Meredith Gregory <lgreg [dot] meredith [at] gmail [dot] com>
> wrote:
>>
>> Dear Ka,
>> Suppose that we have
>> trait Functor[M[_]] {
>>    def fmap [A,B] ( f : A => B ) : M[A] => M[B]
>> }
>> trait Monad[M[_]] extends Functor {
>>    def unit [A] ( a : A ) : M[A]
>>    def mult [A] ( mma : M[M[A]]  ) : M[A]
>> }
>> as before. Further suppose that we have two type constructors, S, T and
>> witnesses to monadic views of these
>> class MonadS extends Monad[S] {
>>    override def unit [A] ( a : A ) : S[A] = { ... }
>>    override def mult [A] ( ssa : S[S[A]]  ) : S[A] = { ... }
>> }
>> class MonadT extends Monad[T] {
>>    override def unit [A] ( a : A ) : T[A] = { ... }
>>    override def mult [A] ( tta : T[T[A]]  ) : T[A] = { ... }
>> }
>> Then we might code a distributive law as something like
>> trait DistributiveLaw[S[_],T[_],MS <: MonadS, MT <: MonadT] {
>>    ...
>>    def distribute [A] ( sta : S[T[A]] ) : T[S[A]]
>> }
>> The constraints that constitute the other data defining a distributive law
>> will have to be verified -- like the monad laws -- by the programmer for
>> each instance.
>> Now, as Eugenia Cheng has shown, if you have two such laws and three
>> monads, S, T, and U, then if you have a hexagonal condition (page 3 of the
>> reference) governing the laws, you will be guaranteed that the composition,
>> STU, (i.e. for type A, S[T[U[A]]]) is a monad and uniquely determined.
>> Moreover, this solution iterates. Further, we see that this architecture
>> smoothly extends to other combinations, comonad/comonad and monad/comonad
>> and gives rise to expected and familiar structures. i believe that this
>> evidence makes the distributive law the preferred choice over the monad
>> transformer. However, a lot more work needs to be done to verify this
>> position.
>> As mentioned on another thread, i suspect it is unwise to ignore the
>> developments that are theoretically and mathematically satisfying as not
>> being "real." It would be wise to remember that the notion of monad, itself,
>> was discovered by mathematicians over 40 years ago.
>> Best wishes,
>> --greg
>>
>> On Fri, Oct 7, 2011 at 11:02 AM, Meredith Gregory
>> <lgreg [dot] meredith [at] gmail [dot] com> wrote:
>>>
>>> Dear Ka,
>>> First of all i want to acknowledge the acuity of your question. A great
>>> deal depends on how natural, effective and intuitive the composition of
>>> monads is. The composition of monads -- what you call nesting --  is not
>>> always guaranteed (by the monad laws) to be a monad.
>>> A monad transformer is one approach to structuring monad composition.
>>> However, let me put in a plug for another: distributive laws. A distributive
>>> law is a map from the type constructor underlying one monad to the type
>>> constructor underlying the other satisfying certain additional constraints.
>>> i'm on my iPhone, so i'll defer more technical exegesis until i can type
>>> at a reasonable speed. Let me just stress that the question you have asked
>>> is at the heart of the larger question of whether monads can provide a more
>>> rational notion of object than object. The critique of OO has been that the
>>> composition mechanism don't -- in practice -- support real reuse. If there's
>>> another proposal on the table, one of our first concerns should be whether
>>> that proposal comes with any better support for composition -- one that
>>> supports effective reuse in practice. So, your question has significantly
>>> raised the level of the conversation.
>>> Best wishes,
>>> --greg
>>>
>>> Managing Partner
>>> Biosimilarity LLC
>>> On Oct 7, 2011, at 6:29, Ka Ter <ter [dot] ka966 [at] googlemail [dot] com> wrote:
>>>
>>> Hi,
>>>
>>> I have a beginner question concerning monads. How would you call a
>>> concept where monads
>>> are nested but are used in a transparent way by users?
>>>
>>> Assume you have a monad M[A]. Then the method 'bind' uses the type A and
>>> produces another type M[B]. When I now have another monad G which wraps
>>> the first one, I now have a G[M[A]]. Now G's bind method refers not to A
>>> but to M[A]. So in case when you have several levels of nesting, for the
>>> user it gets complicated (e.g. I[H[G[M[A]]]]) of using a bind method,
>>> because they also have to be called in a nested way.
>>>
>>> Is there already a concept saying that when having nested monads, there
>>> is some kind of special bind method that only refers to the inner monad?
>>>
>>> In my case I want to work with collections and wrap it by one or more
>>> monads.
>>>
>>> val b: M[List[A]] = ....
>>>
>>> in class M:
>>>   def map(f: A => B): M[List[B]] = .....
>>>
>>> or val g: G[M[A]] = .....
>>>
>>> in class G
>>>    def map(f: A => B): G[M[B]]
>>>
>>> These monads add side-effects (e.g. automatically filter the result
>>> sets; without changing the result type) and should be transparent which
>>> means the user should work with it as if it is only a collection (of
>>> course the collection's interface is overlapped by the one of the monad).
>>>
>>> Is there already a concept for that defined and available?
>>>
>>> --
>>> Best Regards
>>>
>>> Ka Ter
>>>
>>>
>>
>>
>>
>> --
>> L.G. Meredith
>> Managing Partner
>> Biosimilarity LLC
>> 7329 39th Ave SW
>> Seattle, WA 98136
>>
>> +1 206.650.3740
>>
>> http://biosimilarity.blogspot.com
>
>
>
> --
> L.G. Meredith
> Managing Partner
> Biosimilarity LLC
> 7329 39th Ave SW
> Seattle, WA 98136
>
> +1 206.650.3740
>
> http://biosimilarity.blogspot.com
>



--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland