- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Option as applicative functor
Hello,
Is there a good reason why Scala Option is not an applicative functor ? I guess one could seamlessly convert an Option[T] to an Applicative[T] using implicits but still ..
Thanks,
Marius
Is there a good reason why Scala Option is not an applicative functor ? I guess one could seamlessly convert an Option[T] to an Applicative[T] using implicits but still ..
Thanks,
Marius
Re: Option as applicative functor
In particular, I think Monad, Monoid and Functor could be enough to pull in most of the useful parts of Scalaz into general usage.
In particular, applicative style is very handy at times, and I'd love to see it supported in the core in a generic manner. I'm working on expanding Jorge's implicit class Foo(x) proposal to include one that makes type trait usage in Scala more efficient and easier. This I think is a requirement to having Scalaz like abstractions gain general acceptance in Scala.
On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/08/11 02:01, Josh Suereth wrote:
> I'm hoping to convince enough folks to get a few, small number, of type
> traits into the standard library to go along with Numeric.
>
> In particular, I think Monad, Monoid and Functor could be enough to pull in
> most of the useful parts of Scalaz into general usage.
>
> In particular, applicative style is very handy at times, and I'd love to see
> it supported in the core in a generic manner. I'm working on expanding
> Jorge's implicit class Foo(x) proposal to include one that makes type trait
> usage in Scala more efficient and easier. This I think is a requirement to
> having Scalaz like abstractions gain general acceptance in Scala.
>
> On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu wrote:
>
>> Hello,
>>
>> Is there a good reason why Scala Option is not an applicative functor ? I
>> guess one could seamlessly convert an Option[T] to an Applicative[T] using
>> implicits but still ..
>>
>> Thanks,
>> Marius
>>
>
If we could just delay the introduction of the point operation... even
Scala has this bias in its for-comprehensions.
There are many useful operations on, say map+flatMap, for which there
are structures that many not be pointed functors. It is then that you
"go sideways" and introduce the point operation.
Regardless of representation, I would suggest the following levels of
abstraction:
* map
* ap+map
* flatMap+map
...
* map+point
* ap+map+point (aka Applicative)
* flatMap+map+point (aka Monad)
I guess I am encouraging this direction because I came up with it myself
after observing that (to summarise) "not all semigroups are monoids",
then I was subsequently convinced by Edward Kmett about this direction
(while hiding the fact that I was already well-persuaded).
Re: Option as applicative functor
So, in adding Functor + Monad to the std lib, what I really want is a type-class way to enter into for-expressions and the ability to use applicative style on anything and everything in Scala out of the box.
Here's my definition of Functor + Monad:trait Functor[T[_]] { def apply[A](x: A): T[A] // my preferred implementation for 'point' def fmap[A,B](x : T[A])(f : T[A=>B]) : T[B] // ap, but not ap def map[A,B](x : T[A])(f: A=>B) : T[B] = fmap(x, apply(f))}
abstract class Monad[T[_]](functor: Functor[T[_]]) { def flatten[A](m : T[T[A]]) : T[A] def flatMap[A,B](x : T[A])(f : A => T[B]) : T[B] = flatten(functor.map(x)(f)) def apply[A](m: A): T[A] = functor(m)}
Where "flatten" and "apply" are the join + zero of Monoid defined on Functors. In an ideal langauge, you could abstract that all out, but let's be practical.
So, in any case, given those two deifnitons, I should be able to:
def foo[T[_]: Monad,A,B](t: T[A], t2: T[B]) = for { x <- t; y <- t2 } yield doSomething(x,y)
*or*
def makeConnection[T[_]: Functor](url: T[String], user: T[String], pw: T[String]): T[java.sql.Connection] = url <*> user <*> pw apply java.sql.DriverManager.getConnection
This, I'd love to have in the std library. Is there anything that would be 'hurt' in not having an abstraction with just map or just flatMap + map or map + ap? I'm just curious, as I haven't been as far down library design as you have.
Finally, the google doc of my proposal for type traits is almost ready. Want to send it past a few folks to get the "ZOMG WHAT ARE YOU TRYING TO DO, KILL US" comments out of the way first.
- Josh
On Sat, Aug 6, 2011 at 6:35 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
An applicative functor is a special type of functor. Not all functors
are applicative. Indeed, not all functors are pointed functors (all
applicative functors are pointed functors). There are also plenty of
functors that have F[A => B] => F[A] => F[B] but not necessarily point
(A => F[A]).
On 07/08/11 12:04, Josh Suereth wrote:
> What you call Applicative, I call functor, at least from what I understand
> of the raw translation of the laws of Functors to C.S. Functors preserve
> morphisms (i.e. ap) and I'm not really sure it makes sense to call something
> a Functor that does not have a "point" i.e. def point[Functor[_]](a: A):
> Functor[A].
>
> So, in adding Functor + Monad to the std lib, what I really want is a
> type-class way to enter into for-expressions and the ability to use
> applicative style on anything and everything in Scala out of the box.
>
> Here's my definition of Functor + Monad:
> trait Functor[T[_]] {
> def apply[A](x: A): T[A] //
> my preferred implementation for 'point'
> def fmap[A,B](x : T[A])(f : T[A=>B]) : T[B] // ap, but not ap
> def map[A,B](x : T[A])(f: A=>B) : T[B] = fmap(x, apply(f))
> }
>
> abstract class Monad[T[_]](functor: Functor[T[_]]) {
> def flatten[A](m : T[T[A]]) : T[A]
> def flatMap[A,B](x : T[A])(f : A => T[B]) : T[B] =
> flatten(functor.map(x)(f))
> def apply[A](m: A): T[A] = functor(m)
> }
>
> Where "flatten" and "apply" are the join + zero of Monoid defined on
> Functors. In an ideal langauge, you could abstract that all out, but let's
> be practical.
>
> So, in any case, given those two deifnitons, I should be able to:
>
> def foo[T[_]: Monad,A,B](t: T[A], t2: T[B]) = for { x <- t; y <- t2 } yield
> doSomething(x,y)
>
> *or*
>
> def makeConnection[T[_]: Functor](url: T[String], user: T[String], pw:
> T[String]): T[java.sql.Connection] =
> url <*> user <*> pw apply java.sql.DriverManager.getConnection
>
> This, I'd love to have in the std library. Is there anything that would be
> 'hurt' in not having an abstraction with just map or just flatMap + map or
> map + ap? I'm just curious, as I haven't been as far down library design as
> you have.
>
>
> Finally, the google doc of my proposal for type traits is almost ready.
> Want to send it past a few folks to get the "ZOMG WHAT ARE YOU TRYING TO DO,
> KILL US" comments out of the way first.
>
> - Josh
>
>
>
>
> On Sat, Aug 6, 2011 at 6:35 PM, Tony Morris wrote:
>
> On 07/08/11 02:01, Josh Suereth wrote:
>>>> I'm hoping to convince enough folks to get a few, small number, of type
>>>> traits into the standard library to go along with Numeric.
>>>>
>>>> In particular, I think Monad, Monoid and Functor could be enough to pull
> in
>>>> most of the useful parts of Scalaz into general usage.
>>>>
>>>> In particular, applicative style is very handy at times, and I'd love to
> see
>>>> it supported in the core in a generic manner. I'm working on expanding
>>>> Jorge's implicit class Foo(x) proposal to include one that makes type
> trait
>>>> usage in Scala more efficient and easier. This I think is a requirement
> to
>>>> having Scalaz like abstractions gain general acceptance in Scala.
>>>>
>>>> On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu >>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Is there a good reason why Scala Option is not an applicative functor ?
> I
>>>>> guess one could seamlessly convert an Option[T] to an Applicative[T]
> using
>>>>> implicits but still ..
>>>>>
>>>>> Thanks,
>>>>> Marius
>>>>>
>>>>
>
> If we could just delay the introduction of the point operation... even
> Scala has this bias in its for-comprehensions.
>
> There are many useful operations on, say map+flatMap, for which there
> are structures that many not be pointed functors. It is then that you
> "go sideways" and introduce the point operation.
>
> Regardless of representation, I would suggest the following levels of
> abstraction:
> * map
> * ap+map
> * flatMap+map
> ...
> * map+point
> * ap+map+point (aka Applicative)
> * flatMap+map+point (aka Monad)
>
> I guess I am encouraging this direction because I came up with it myself
> after observing that (to summarise) "not all semigroups are monoids",
> then I was subsequently convinced by Edward Kmett about this direction
> (while hiding the fact that I was already well-persuaded).
>
>
>>
Re: Option as applicative functor
On Sun, Aug 7, 2011 at 3:30 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
This of course, implies that they are Functors of the empty set.
So first, I think I messed up my terminology. Applicative ( F[A=>B] => F[A] => F[B] ) is indeed *not* defined for all Functors. Functors 'preserve morphisms' which is, they define (A=>B) => (F[A] => F[B]) which is simply the 'map' operation, not fmap. So, I totally understand the need for a separate Applicative trait now.
Now, Some Functors do not have direct constructors on all types, but if they are not over the empty-set of types, one can derive a generic apply *if and only if* there is exactly one F[A] that can be constructed and 'map' is defined for all functions A=>B and functor instances F[A]. That is:
Given a single instance of F[X], I can define point as: def point[A](a: A) = instanceOfF.map(ignore => a)
This isn't particularly useful, but it means that for all Functors defined against non-empty categories that also have a map function that spans all types, given a single 'point' manipulation, I can derive a point opreation for all possible types and values.
I think the issue here is one of practicality. For example, the ManagedResource[_] trait in my scala-arm library defines a map operation that works across all possible function A => B. However, the constructor for ManagedResource[_] only accepts types that are supported with an implicit Resource type class. So, you could use these to say that ManagedResource is a Functor defined on types that are supported with Resource type classes. Defining this in Scala is difficult/impractical in the type system. However, since the map operation is define on all types, we can construct a point operation given any ManagedResource. Again, this is impractical in real-lift code.
So, while I disagree on terminology, I do agree that I think you may have outlined the abstractions appropriately. I'd like to choose a new non-confusing name first though :)
I think these abstractions are the only ones I'd like to see directly...
map + ap (for Applicative style usage)map + flatMap (for Monads + for expression)map + flatMap + withFilter (stronger for expression)
As for point, although I'd argue that if you support any of those abstraction, you can construct a point operation as long as your category F[_] is non-empty... it's also impractical for certain types of Functors.
- Josh
Re: Option as applicative functor
In any case, are you interested in developing a small subset(the least controversial) of scalaz to push into scala-incubator. If we start now, we can hopefully gain enough traction.
On Aug 7, 2011 11:29 AM, "Josh Suereth" <joshua [dot] suereth [at] gmail [dot] com> wrote:> On Sun, Aug 7, 2011 at 3:30 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> An applicative functor is a special type of functor. Not all functors
>> are applicative. Indeed, not all functors are pointed functors (all
>> applicative functors are pointed functors). There are also plenty of
>> functors that have F[A => B] => F[A] => F[B] but not necessarily point
>> (A => F[A]).
>>
>>
> This of course, implies that they are Functors of the empty set.
>
> So first, I think I messed up my terminology. Applicative ( F[A=>B] => F[A]
> => F[B] ) is indeed *not* defined for all Functors. Functors 'preserve
> morphisms' which is, they define (A=>B) => (F[A] => F[B]) which is simply
> the 'map' operation, not fmap. So, I totally understand the need for a
> separate Applicative trait now.
>
> Now, Some Functors do not have direct constructors on all types, but if they
> are not over the empty-set of types, one can derive a generic apply *if and
> only if* there is exactly one F[A] that can be constructed and 'map' is
> defined for all functions A=>B and functor instances F[A]. That is:
>
> Given a single instance of F[X], I can define point as: def point[A](a: A)
> = instanceOfF.map(ignore => a)
>
> This isn't particularly useful, but it means that for all Functors defined
> against non-empty categories that also have a map function that spans all
> types, given a single 'point' manipulation, I can derive a point opreation
> for all possible types and values.
>
> I think the issue here is one of practicality. For example, the
> ManagedResource[_] trait in my scala-arm library defines a map operation
> that works across all possible function A => B. However, the constructor
> for ManagedResource[_] only accepts types that are supported with an
> implicit Resource type class. So, you could use these to say that
> ManagedResource is a Functor defined on types that are supported with
> Resource type classes. Defining this in Scala is difficult/impractical in
> the type system. However, since the map operation is define on all types,
> we can construct a point operation given any ManagedResource. Again, this
> is impractical in real-lift code.
>
> So, while I disagree on terminology, I do agree that I think you may have
> outlined the abstractions appropriately. I'd like to choose a new
> non-confusing name first though :)
>
> I think these abstractions are the only ones I'd like to see directly...
>
> map + ap (for Applicative style usage)
> map + flatMap (for Monads + for expression)
> map + flatMap + withFilter (stronger for expression)
>
> As for point, although I'd argue that if you support any of those
> abstraction, you can construct a point operation as long as your category
> F[_] is non-empty... it's also impractical for certain types of Functors.
>
> - Josh
>
>
>
>
>> On 07/08/11 12:04, Josh Suereth wrote:
>> > What you call Applicative, I call functor, at least from what I
>> understand
>> > of the raw translation of the laws of Functors to C.S. Functors
>> preserve
>> > morphisms (i.e. ap) and I'm not really sure it makes sense to call
>> something
>> > a Functor that does not have a "point" i.e. def point[Functor[_]](a: A):
>> > Functor[A].
>> >
>> > So, in adding Functor + Monad to the std lib, what I really want is a
>> > type-class way to enter into for-expressions and the ability to use
>> > applicative style on anything and everything in Scala out of the box.
>> >
>> > Here's my definition of Functor + Monad:
>> > trait Functor[T[_]] {
>> > def apply[A](x: A): T[A] //
>> > my preferred implementation for 'point'
>> > def fmap[A,B](x : T[A])(f : T[A=>B]) : T[B] // ap, but not ap
>> > def map[A,B](x : T[A])(f: A=>B) : T[B] = fmap(x, apply(f))
>> > }
>> >
>> > abstract class Monad[T[_]](functor: Functor[T[_]]) {
>> > def flatten[A](m : T[T[A]]) : T[A]
>> > def flatMap[A,B](x : T[A])(f : A => T[B]) : T[B] =
>> > flatten(functor.map(x)(f))
>> > def apply[A](m: A): T[A] = functor(m)
>> > }
>> >
>> > Where "flatten" and "apply" are the join + zero of Monoid defined on
>> > Functors. In an ideal langauge, you could abstract that all out, but
>> let's
>> > be practical.
>> >
>> > So, in any case, given those two deifnitons, I should be able to:
>> >
>> > def foo[T[_]: Monad,A,B](t: T[A], t2: T[B]) = for { x <- t; y <- t2 }
>> yield
>> > doSomething(x,y)
>> >
>> > *or*
>> >
>> > def makeConnection[T[_]: Functor](url: T[String], user: T[String], pw:
>> > T[String]): T[java.sql.Connection] =
>> > url <*> user <*> pw apply java.sql.DriverManager.getConnection
>> >
>> > This, I'd love to have in the std library. Is there anything that would
>> be
>> > 'hurt' in not having an abstraction with just map or just flatMap + map
>> or
>> > map + ap? I'm just curious, as I haven't been as far down library design
>> as
>> > you have.
>> >
>> >
>> > Finally, the google doc of my proposal for type traits is almost ready.
>> > Want to send it past a few folks to get the "ZOMG WHAT ARE YOU TRYING TO
>> DO,
>> > KILL US" comments out of the way first.
>> >
>> > - Josh
>> >
>> >
>> >
>> >
>> > On Sat, Aug 6, 2011 at 6:35 PM, Tony Morris <tonymorris [at] gmail [dot] com>
>> wrote:
>> >
>> > On 07/08/11 02:01, Josh Suereth wrote:
>> >>>> I'm hoping to convince enough folks to get a few, small number, of
>> type
>> >>>> traits into the standard library to go along with Numeric.
>> >>>>
>> >>>> In particular, I think Monad, Monoid and Functor could be enough to
>> pull
>> > in
>> >>>> most of the useful parts of Scalaz into general usage.
>> >>>>
>> >>>> In particular, applicative style is very handy at times, and I'd love
>> to
>> > see
>> >>>> it supported in the core in a generic manner. I'm working on
>> expanding
>> >>>> Jorge's implicit class Foo(x) proposal to include one that makes type
>> > trait
>> >>>> usage in Scala more efficient and easier. This I think is a
>> requirement
>> > to
>> >>>> having Scalaz like abstractions gain general acceptance in Scala.
>> >>>>
>> >>>> On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu <
>> marius [dot] danciu [at] gmail [dot] com
>> >>>> wrote:
>> >>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Is there a good reason why Scala Option is not an applicative functor
>> ?
>> > I
>> >>>>> guess one could seamlessly convert an Option[T] to an Applicative[T]
>> > using
>> >>>>> implicits but still ..
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Marius
>> >>>>>
>> >>>>
>> >
>> > If we could just delay the introduction of the point operation... even
>> > Scala has this bias in its for-comprehensions.
>> >
>> > There are many useful operations on, say map+flatMap, for which there
>> > are structures that many not be pointed functors. It is then that you
>> > "go sideways" and introduce the point operation.
>> >
>> > Regardless of representation, I would suggest the following levels of
>> > abstraction:
>> > * map
>> > * ap+map
>> > * flatMap+map
>> > ...
>> > * map+point
>> > * ap+map+point (aka Applicative)
>> > * flatMap+map+point (aka Monad)
>> >
>> > I guess I am encouraging this direction because I came up with it myself
>> > after observing that (to summarise) "not all semigroups are monoids",
>> > then I was subsequently convinced by Edward Kmett about this direction
>> > (while hiding the fact that I was already well-persuaded).
>> >
>> >
>> >>
>>
>> - --
>> Tony Morris
>> http://tmorris.net/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJOPj8EAAoJEPxHMY3rBz0PUgUH/iuqH7Fm4zC5QnTM40CWXU8m
>> i88Kek5DDycJYro5caVYxB1Lz3v57ILXlEqWNZDgo7xBf/2EvWvbVgZKC1MY9cq+
>> RkggKm5XMMaxLzD3B865VF11HoNTB5nT7MWPcpxh5agrSbtLJK3Q1yubOU3H++SO
>> LycwJDFymfYn22iyvvb1/+xpudN1dSpmyJ5ZgJrReB9aXaR4I9Be9kx8ZmO+Cjxk
>> rzg/QoMFGvNTa0V0PVQn5J/5V2t79ZnzM30lPaxU5JPKdwlYiPbrUWgCLh3aBMfj
>> jqAXXHRwE1TcvWLkBdsgwfSGDKbLKlNyGQ+vvC8azQSX5f3n3O/Orr/gHPr/Qpc=
>> =Kc2K
>> -----END PGP SIGNATURE-----
>>
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sure! Though I never can work out which is most controversial.
On 08/08/11 07:38, Josh Suereth wrote:
> In any case, are you interested in developing a small subset(the least
> controversial) of scalaz to push into scala-incubator. If we start now, we
> can hopefully gain enough traction.
> On Aug 7, 2011 11:29 AM, "Josh Suereth" wrote:
>> On Sun, Aug 7, 2011 at 3:30 AM, Tony Morris wrote:
>>
> An applicative functor is a special type of functor. Not all functors
> are applicative. Indeed, not all functors are pointed functors (all
> applicative functors are pointed functors). There are also plenty of
> functors that have F[A => B] => F[A] => F[B] but not necessarily point
> (A => F[A]).
>
>
>>> This of course, implies that they are Functors of the empty set.
>>>
>>> So first, I think I messed up my terminology. Applicative ( F[A=>B] =>
>> F[A]
>>> => F[B] ) is indeed *not* defined for all Functors. Functors 'preserve
>>> morphisms' which is, they define (A=>B) => (F[A] => F[B]) which is simply
>>> the 'map' operation, not fmap. So, I totally understand the need for a
>>> separate Applicative trait now.
>>>
>>> Now, Some Functors do not have direct constructors on all types, but if
>> they
>>> are not over the empty-set of types, one can derive a generic apply *if
>> and
>>> only if* there is exactly one F[A] that can be constructed and 'map' is
>>> defined for all functions A=>B and functor instances F[A]. That is:
>>>
>>> Given a single instance of F[X], I can define point as: def point[A](a: A)
>>> = instanceOfF.map(ignore => a)
>>>
>>> This isn't particularly useful, but it means that for all Functors defined
>>> against non-empty categories that also have a map function that spans all
>>> types, given a single 'point' manipulation, I can derive a point opreation
>>> for all possible types and values.
>>>
>>> I think the issue here is one of practicality. For example, the
>>> ManagedResource[_] trait in my scala-arm library defines a map operation
>>> that works across all possible function A => B. However, the constructor
>>> for ManagedResource[_] only accepts types that are supported with an
>>> implicit Resource type class. So, you could use these to say that
>>> ManagedResource is a Functor defined on types that are supported with
>>> Resource type classes. Defining this in Scala is difficult/impractical in
>>> the type system. However, since the map operation is define on all types,
>>> we can construct a point operation given any ManagedResource. Again, this
>>> is impractical in real-lift code.
>>>
>>> So, while I disagree on terminology, I do agree that I think you may have
>>> outlined the abstractions appropriately. I'd like to choose a new
>>> non-confusing name first though :)
>>>
>>> I think these abstractions are the only ones I'd like to see directly...
>>>
>>> map + ap (for Applicative style usage)
>>> map + flatMap (for Monads + for expression)
>>> map + flatMap + withFilter (stronger for expression)
>>>
>>> As for point, although I'd argue that if you support any of those
>>> abstraction, you can construct a point operation as long as your category
>>> F[_] is non-empty... it's also impractical for certain types of Functors.
>>>
>>> - Josh
>>>
>>>
>>>
>>>
> On 07/08/11 12:04, Josh Suereth wrote:
>>>>> What you call Applicative, I call functor, at least from what I
> understand
>>>>> of the raw translation of the laws of Functors to C.S. Functors
> preserve
>>>>> morphisms (i.e. ap) and I'm not really sure it makes sense to call
> something
>>>>> a Functor that does not have a "point" i.e. def point[Functor[_]](a:
>> A):
>>>>> Functor[A].
>>>>>
>>>>> So, in adding Functor + Monad to the std lib, what I really want is a
>>>>> type-class way to enter into for-expressions and the ability to use
>>>>> applicative style on anything and everything in Scala out of the box.
>>>>>
>>>>> Here's my definition of Functor + Monad:
>>>>> trait Functor[T[_]] {
>>>>> def apply[A](x: A): T[A] //
>>>>> my preferred implementation for 'point'
>>>>> def fmap[A,B](x : T[A])(f : T[A=>B]) : T[B] // ap, but not ap
>>>>> def map[A,B](x : T[A])(f: A=>B) : T[B] = fmap(x, apply(f))
>>>>> }
>>>>>
>>>>> abstract class Monad[T[_]](functor: Functor[T[_]]) {
>>>>> def flatten[A](m : T[T[A]]) : T[A]
>>>>> def flatMap[A,B](x : T[A])(f : A => T[B]) : T[B] =
>>>>> flatten(functor.map(x)(f))
>>>>> def apply[A](m: A): T[A] = functor(m)
>>>>> }
>>>>>
>>>>> Where "flatten" and "apply" are the join + zero of Monoid defined on
>>>>> Functors. In an ideal langauge, you could abstract that all out, but
> let's
>>>>> be practical.
>>>>>
>>>>> So, in any case, given those two deifnitons, I should be able to:
>>>>>
>>>>> def foo[T[_]: Monad,A,B](t: T[A], t2: T[B]) = for { x <- t; y <- t2 }
> yield
>>>>> doSomething(x,y)
>>>>>
>>>>> *or*
>>>>>
>>>>> def makeConnection[T[_]: Functor](url: T[String], user: T[String], pw:
>>>>> T[String]): T[java.sql.Connection] =
>>>>> url <*> user <*> pw apply java.sql.DriverManager.getConnection
>>>>>
>>>>> This, I'd love to have in the std library. Is there anything that would
> be
>>>>> 'hurt' in not having an abstraction with just map or just flatMap + map
> or
>>>>> map + ap? I'm just curious, as I haven't been as far down library
>> design
> as
>>>>> you have.
>>>>>
>>>>>
>>>>> Finally, the google doc of my proposal for type traits is almost ready.
>>>>> Want to send it past a few folks to get the "ZOMG WHAT ARE YOU TRYING
>> TO
> DO,
>>>>> KILL US" comments out of the way first.
>>>>>
>>>>> - Josh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 6, 2011 at 6:35 PM, Tony Morris
> wrote:
>>>>>
>>>>> On 07/08/11 02:01, Josh Suereth wrote:
>>>>>>>> I'm hoping to convince enough folks to get a few, small number, of
> type
>>>>>>>> traits into the standard library to go along with Numeric.
>>>>>>>>
>>>>>>>> In particular, I think Monad, Monoid and Functor could be enough to
> pull
>>>>> in
>>>>>>>> most of the useful parts of Scalaz into general usage.
>>>>>>>>
>>>>>>>> In particular, applicative style is very handy at times, and I'd
>> love
> to
>>>>> see
>>>>>>>> it supported in the core in a generic manner. I'm working on
> expanding
>>>>>>>> Jorge's implicit class Foo(x) proposal to include one that makes
>> type
>>>>> trait
>>>>>>>> usage in Scala more efficient and easier. This I think is a
> requirement
>>>>> to
>>>>>>>> having Scalaz like abstractions gain general acceptance in Scala.
>>>>>>>>
>>>>>>>> On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu <
> marius [dot] danciu [at] gmail [dot] com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Is there a good reason why Scala Option is not an applicative
>> functor
> ?
>>>>> I
>>>>>>>>> guess one could seamlessly convert an Option[T] to an
>> Applicative[T]
>>>>> using
>>>>>>>>> implicits but still ..
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Marius
>>>>>>>>>
>>>>>>>>
>>>>>
>>>>> If we could just delay the introduction of the point operation... even
>>>>> Scala has this bias in its for-comprehensions.
>>>>>
>>>>> There are many useful operations on, say map+flatMap, for which there
>>>>> are structures that many not be pointed functors. It is then that you
>>>>> "go sideways" and introduce the point operation.
>>>>>
>>>>> Regardless of representation, I would suggest the following levels of
>>>>> abstraction:
>>>>> * map
>>>>> * ap+map
>>>>> * flatMap+map
>>>>> ...
>>>>> * map+point
>>>>> * ap+map+point (aka Applicative)
>>>>> * flatMap+map+point (aka Monad)
>>>>>
>>>>> I guess I am encouraging this direction because I came up with it
>> myself
>>>>> after observing that (to summarise) "not all semigroups are monoids",
>>>>> then I was subsequently convinced by Edward Kmett about this direction
>>>>> (while hiding the fact that I was already well-persuaded).
>>>>>
>>>>>
>>>>>>
>
>>>
Re: Option as applicative functor
Just wondering...
Which package name do you intend to use?
Thanks and bye,
Simon
Re: Option as applicative functor
On Sun, Aug 7, 2011 at 6:23 PM, Simon Ochsenreither <simon [at] ochsenreither [dot] de> wrote:
Re: Option as applicative functor
See, actually by applicative (in cartesian-closed categories), I believe they mean preservation of exponent.
F[X] x F[Y^X] -> F[Y]
http://presheaf.com/cache/d211k3i3k6qw6r5e2wq5m3a1x4nt59.png
Thanks,
-Vlad
On Sat, Aug 6, 2011 at 7:04 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Re: Option as applicative functor
That'd be great and I'm sure that a lot of folks are looking for this.
On Aug 6, 2011 7:01 PM, "Josh Suereth" <joshua [dot] suereth [at] gmail [dot] com> wrote:> I'm hoping to convince enough folks to get a few, small number, of type
> traits into the standard library to go along with Numeric.
>
> In particular, I think Monad, Monoid and Functor could be enough to pull in
> most of the useful parts of Scalaz into general usage.
>
> In particular, applicative style is very handy at times, and I'd love to see
> it supported in the core in a generic manner. I'm working on expanding
> Jorge's implicit class Foo(x) proposal to include one that makes type trait
> usage in Scala more efficient and easier. This I think is a requirement to
> having Scalaz like abstractions gain general acceptance in Scala.
>
> On Sat, Aug 6, 2011 at 7:27 AM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com>wrote:
>
>> Hello,
>>
>> Is there a good reason why Scala Option is not an applicative functor ? I
>> guess one could seamlessly convert an Option[T] to an Applicative[T] using
>> implicits but still ..
>>
>> Thanks,
>> Marius
>>
Re: Option as applicative functor
On Sat, Aug 06, 2011 at 12:01:03PM -0400, Josh Suereth wrote:
> In particular, applicative style is very handy at times, and I'd love to see
> it supported in the core in a generic manner. I'm working on expanding
> Jorge's implicit class Foo(x) proposal to include one that makes type trait
> usage in Scala more efficient and easier. This I think is a requirement to
> having Scalaz like abstractions gain general acceptance in Scala.
Ever since your earlier email about this I've been interested and
waiting to see what you have. Anything you can share yet? I'd love to
be a sounding board on this, given that it could really aid the work
I'm doing with Numeric.
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/08/11 21:27, Marius Danciu wrote:
> Hello,
>
> Is there a good reason why Scala Option is not an applicative functor ? I
> guess one could seamlessly convert an Option[T] to an Applicative[T] using
> implicits but still ..
>
> Thanks,
> Marius
>
Which Applicative do you mean? For the one in scalaz, there is an
implementation for Option.
Do you want a method on Option[T] taking an Option[T => U], returning
Option[U]?
Re: Option as applicative functor
Marius
On Sat, Aug 6, 2011 at 3:35 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well then that would require such a method on many type constructors,
and the body of these methods would be a copy/paste show.
def <*>[B](f: F[A => B]): F[B] = for { ff <- f; aa <- this } yield ff(aa)
On 06/08/11 22:52, Marius Danciu wrote:
> Precisely.
>
> Marius
>
> On Sat, Aug 6, 2011 at 3:35 PM, Tony Morris wrote:
>
> On 06/08/11 21:27, Marius Danciu wrote:
>>>> Hello,
>>>>
>>>> Is there a good reason why Scala Option is not an applicative functor ? I
>>>> guess one could seamlessly convert an Option[T] to an Applicative[T]
> using
>>>> implicits but still ..
>>>>
>>>> Thanks,
>>>> Marius
>>>>
>
> Which Applicative do you mean? For the one in scalaz, there is an
> implementation for Option.
>
> Do you want a method on Option[T] taking an Option[T => U], returning
> Option[U]?
>
>
>>
Re: Option as applicative functor
Thanks,
Marius
On Sat, Aug 6, 2011 at 3:54 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
Re: Option as applicative functor
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You could say that about an enormous number of traits.
There is a "growing movement" of people who delay introduction of the
unit operation, so you'd have a trait with ap+fmap instead (semigroups
instead of monoids).
On 06/08/11 23:03, Marius Danciu wrote:
> Right, but I guess here could have been an Applicative[T[_]] trait that
> those type constructors such as Option would mixin with, avoiding copy-paste
> in many cases. Applicative would probably have to extend Functor[T[_]] for
> having unit and fmap.
>
> Thanks,
> Marius
>
> On Sat, Aug 6, 2011 at 3:54 PM, Tony Morris wrote:
>
> Well then that would require such a method on many type constructors,
> and the body of these methods would be a copy/paste show.
>
> def <*>[B](f: F[A => B]): F[B] = for { ff <- f; aa <- this } yield ff(aa)
>
>
> On 06/08/11 22:52, Marius Danciu wrote:
>>>> Precisely.
>>>>
>>>> Marius
>>>>
>>>> On Sat, Aug 6, 2011 at 3:35 PM, Tony Morris
> wrote:
>>>>
>>>> On 06/08/11 21:27, Marius Danciu wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Is there a good reason why Scala Option is not an applicative functor
> ? I
>>>>>>> guess one could seamlessly convert an Option[T] to an Applicative[T]
>>>> using
>>>>>>> implicits but still ..
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marius
>>>>>>>
>>>>
>>>> Which Applicative do you mean? For the one in scalaz, there is an
>>>> implementation for Option.
>>>>
>>>> Do you want a method on Option[T] taking an Option[T => U], returning
>>>> Option[U]?
>>>>
>>>>
>>>>>
>
>>
Re: Option as applicative functor
I still think that nested traits
- the outer one containing stuff like unit and join
- the inner one containing stuff like map (>=) and ap (<*>)
is a valuable alternative
the outer traits, eventually, become something like
- an implicit identityMonad,
- an implicit stateTransformedIdentityMonad
- an implicit controlTransformedIdentityMonad
- ...
the inner traits, eventually, become case classes
agreed: it adds some complexity
ps:
personally I hope that this new DOT (dependent object types) approach
will work nicely with nested traits
Luc
On Sat, Aug 6, 2011 at 3:05 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Option as applicative functor
anyway
if Option[T] is a Monad[T] and the library (somehow) considers a Monad[T] as an Applicative[T]
then Option[T] is an Applicative[T] as well
in general, monads are applicative as follows
app(mf, mx) = for { x <- mx ; f <- mf } yield f(x)
Luc
On Sat, Aug 6, 2011 at 1:27 PM, Marius Danciu <marius [dot] danciu [at] gmail [dot] com> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Re: Option as applicative functor
I'm referring to scala.Option.
Thanks,
Marius
On Sat, Aug 6, 2011 at 2:35 PM, Luc Duponcheel <luc [dot] duponcheel [at] gmail [dot] com> wrote: