Implicits in 'Scala by Example'

On Sun, Sep 25, 2011 at 07:15:24AM -0700, Lg wrote:
> The only way I could get the example to work was to add an implicit
> definition to the Monoid object. This is not ideal as the Monoid
> class should not have to know about the Int Monoid.

You can simulate the effect of top-level implicits by importing from an
object, e.g.:

package demo

...

object MyImplicits {
implicit def intMonoid = new IntMonoid {}
}

import MyImplicits.intMonoid // or import MyImplicits._

...

You could also use something like a package object for this.

On Sun, Sep 25, 2011 at 10:50:16AM -0400, Erik Osheim wrote:
> You can simulate the effect of top-level implicits by importing from an
> object, e.g.:

So I totally messed up the indenting. It shouldn't matter but I don't
want to give the wrong idea. This is what I meant:

package demo
...
object MyImplicits {
implicit def intMonoid = new IntMonoid {}
}
import MyImplicits.intMonoid // or import MyImplicits._
...

The implicits were never meant to be put at the top level -- you
should have put them in the scope of the tests.

However, though this is not mentioned there, the best places for an
implicit A => B are inside the object companions of A and B (used with
view bounds), in that order, and the best place for an implicit A[B]
are on the object companions of A and B (used with context bounds), in
any order. This puts the implicits in the scope that will be searched
by the compiler.

Since you can't change String or Int, putting these implicits inside
Monoid object companion will make them work

On Sun, Sep 25, 2011 at 11:15, Lg wrote:
> The Monoid example as described in the document 'Scala by Example', no
> longer works because implicits are not permitted at the top level.
> What is the correct fix for the example?
>
> The only way I could get the example to work was to add an implicit
> definition to the Monoid object.   This is not ideal as the Monoid
> class should not have to know about the Int Monoid.
>
> Thanks.
>
> Best,
>    Lal
>
> ---------------Monoid.scala-----------------
> package demo
>
>          // unchanged
> abstract class SemiGroup[A] {
>    def add(x: A, y:A) : A
> }
>
>        // unchanged
> abstract class Monoid[A] extends SemiGroup[A] {
>    def unit : A
> }
>
>      // added
> object Monoid {
>    implicit def intMonoid : Monoid[Int] = new
> IntMonoid{}                       // <-----------
> }
>
> ---------------IntMonoid.scala--------------------
> package demo
>
> // changed to trait
> trait IntMonoid extends Monoid[Int]  {
>    def add(x: Int, y: Int) : Int = x + y
>    def unit : Int = 0
> }
>
> ---------------App.scala------------------------
> package demo
>
> object App {
>    def sum[A](xs: List[A]) (implicit m: Monoid[A]) : A =
>        if (xs.isEmpty) m.unit
>        else m.add(xs.head, sum(xs.tail))
> }
>

On Sun, Sep 25, 2011 at 12:24:00PM -0300, Daniel Sobral wrote:
> However, though this is not mentioned there, the best places for an
> implicit A => B are inside the object companions of A and B (used with
> view bounds), in that order, and the best place for an implicit A[B]
> are on the object companions of A and B (used with context bounds), in
> any order. This puts the implicits in the scope that will be searched
> by the compiler.

You're quite right Daniel, but one of the benefits of the type class
pattern (at least in Haskell) is that type classes are extensible and
loosely-coupled with the member types. That is, you should be able to
add a type A to type class Foo without having to modify the definition
of A or Foo.

I just gave a presentation on the type class pattern in Scala so I'm
very attuned to this shortcoming. It's certainly nice to not require
the user to do any importing, but that does create unnecessary coupling
between the type class and the member type. I think this is what the
original poster is objecting to.