- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Nested monads
Fri, 2011-10-07, 14:29
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
Fri, 2011-10-07, 17:07
#2
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:
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
Fri, 2011-10-07, 17:07
#3
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
Fri, 2011-10-07, 17:27
#4
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>
:)
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
Fri, 2011-10-07, 17:47
#5
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.
Fri, 2011-10-07, 19:07
#6
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:
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
Fri, 2011-10-07, 20:27
#7
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.
Am 07.10.2011 20:02, schrieb Meredith Gregory:
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
Fri, 2011-10-07, 20:37
#8
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
Sat, 2011-10-08, 00:57
#9
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:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
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
Sat, 2011-10-08, 01:07
#10
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:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
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
Sat, 2011-10-08, 01:37
#11
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
>
Sat, 2011-10-08, 01:47
#12
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:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
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
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: