Add `instance` support: about simulacrum

[mpilquist]

One thing to note with this syntax is that it wouldn't support multiple parameter lists designed to encourage type inference and syntax. For example, Monod.instance might be defined as:

def instance[A](id: A)(append: (A, A) => A): Monoid[A]

This definition works nicer with Scala's type inferencing rules. E.g., in Monoid.instance(0)(_ + _), A is correctly inferred as Int whereas in Monoid.instance(0, _ + _), Scala is not able to infer that the second param is a Function2[Int, Int, Int].

I don't think this is a blocker though -- folks can always define their own instance methods that are hand crafted to these types of situations. Just an observation.

[erikkaplun]

To me, Monoid.instance[Int](...) is preferrable anyway rather than leaving off the type parameter. In Haskell you also declare it explicitly: instance Monoid Int where.

[fommil]

Found myself wanting something like this today. Makes sense when creating instances for typeclasses that have only one abstract method on them.

@typeclass trait UrlEncoded[T] {
  def urlEncoded(t: T): String
}

could helpfully generate

   def instance[T](body: T => String): UrlEncoded[T] = new UrlEncoded[T] {
     override def urlEncoded(t: T): String = body(t)
   }

on the companion allowing all the primitive impls to save on boilerplate. e.g.

implicit val urlEncodedString: UrlEncoded[String] = instance { s => URLEncoder.encode(s, "UTF-8") }

// @SystemFw

[fommil]

I'm wondering if there is something even more radical we could do. Imagine "first class instances" on the companion like this (for a typeclass F with a single abstract method that returns B)

def instance(f: Foo): B = ...

that would get converted into

implicit val FFoo: F[Foo] = instance(f => ... )

(or the longer form without instance).

I'm not sure if the @typeclass on the trait would allow for messing with the companion, or if the overloading of methods named instance would get as far as the macro stage... but it'd be lovely if it worked!