Why does applicative require it's own type trait?

32 views
Skip to first unread message

Josh Suereth

unread,
Aug 5, 2011, 5:50:17 PM8/5/11
to sca...@googlegroups.com
Just curious why Applicative requires it's own type trait, when everything can be implemented in terms of Functor.   Here's an alternative implementation of the Applicative builder....

object Applicative {
  implicit def makeBuilder[F[_]:Functor,A](m: F[A]) = new ApplicativeBuilder[F,A](m)
  def apply[F[_]:Functor, A](m: F[A]) = makeBuilder(m)
}

class ApplicativeBuilder[F[_],A](ma: F[A])(implicit functor: Functor[F]) {
  def <*>[B](mb: F[B]) = new ApplicativeBuilder2(mb)
  class ApplicativeBuilder2[B](mb: F[B]) {
    import Implicits._
    def apply[C](f: (A, B) => C): F[C] = mb.fmap(ma.map(f.curried))
    def <*>[C](mc: F[C]) = new AppplicativeBuilder3[C](mc)
    class AppplicativeBuilder3[C](mc: F[C]) {
      def apply[D](f: (A,B,C) => D): F[D] = mc.fmap(mb.fmap(ma.map(f.curried)))
      def <*>[D](md: F[D]) = new ApplicativeBuilder4[D](md)
      class ApplicativeBuilder4[D](md: F[D]) {
        def apply[E](f: (A,B,C,D) => E): F[E] = md.fmap(mc.fmap(mb.fmap(ma.map(f.curried))))
        def <*>[E](me: F[E]) = new ApplicativeBuilder5[E](me)
        class ApplicativeBuilder5[E](me: F[E]) {
          def apply[R](f: (A,B,C,D,E) => R): F[R] = me.fmap(md.fmap(mc.fmap(mb.fmap(ma.map(f.curried)))))
        }
      }
    }
  }
}


Of course, I could be completely missing the point of the Applic type trait vs. using <*> for applicative style...

Runar Oli

unread,
Aug 7, 2011, 8:48:14 AM8/7/11
to sca...@googlegroups.com, sca...@googlegroups.com
That's not correct though. Does this code typecheck?
--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To post to this group, send email to sca...@googlegroups.com.
To unsubscribe from this group, send email to scalaz+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scalaz?hl=en.

Josh Suereth

unread,
Aug 7, 2011, 11:35:56 AM8/7/11
to sca...@googlegroups.com
It type checks and works.   However, this is because I mistakenly put fmap into Functor.   I just realized my mistake and am pulling fmap into its own type trait.

BTW - This is my attempt to redesign portions of Scalaz in Chapter 11 of Scala In Depth.   I'm hoping this can give people enough insight into the concepts to get into the powers inherit in the library before your own book is available.

In any case, it seems my confusion was in the definition of functions.   Scalaz calls 'ap' that which I call 'fmap' and 'apply' that which I call 'map'.

It appears we are in violent agreement and again I've been confused by names.

Runar Oli

unread,
Aug 7, 2011, 11:59:41 AM8/7/11
to sca...@googlegroups.com, sca...@googlegroups.com
Oh! I was reading fmap as having type (a -> b) -> f a -> f b

Glad we cleared that up.

y

unread,
Aug 8, 2011, 8:29:54 PM8/8/11
to scalaz
Excellent idea for Chapter 11. I already preordered. The book's gonna
be a must-have for people interested in Scala ...

On Aug 7, 11:35 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
> It type checks and works.   However, this is because I mistakenly put fmap
> into Functor.   I just realized my mistake and am pulling fmap into its own
> type trait.
>
> BTW - This is my attempt to redesign portions of Scalaz in Chapter 11 of
> Scala In Depth.   I'm hoping this can give people enough insight into the
> concepts to get into the powers inherit in the library before your own book
> is available.
>
> In any case, it seems my confusion was in the definition of functions.
> Scalaz calls 'ap' that which I call 'fmap' and 'apply' that which I call
> 'map'.
>
> It appears we are in violent agreement and again I've been confused by
> names.
>
>
>
>
>
>
>
> On Sun, Aug 7, 2011 at 8:48 AM, Runar Oli <runaror...@gmail.com> wrote:
> > That's not correct though. Does this code typecheck?
>
Reply all
Reply to author
Forward
0 new messages