Where is implicitly's implicit "e" defined?

70 views
Skip to first unread message

Nader Aeinehchi

unread,
Nov 18, 2012, 10:08:41 AM11/18/12
to scala...@googlegroups.com
Hello

In scala.collection.mutable.ArrayBuilder, there is this definition

<code>def make[T: ClassManifest](): ArrayBuilder[T] =implicitly[ClassManifest[T]].newArrayBuilder()</code>

I can see that <code>implicitly</code> is defined in Predef class as:

<code>def implicitly[T](implicit e: T) = e </code>

Where is the implicit "e" defined in order to be used in ArrayBuilder's "make" method?

In advance thank you very much.

Nader Aeinehchi

sschaef

unread,
Nov 18, 2012, 1:21:01 PM11/18/12
to scala...@googlegroups.com
make has a context bound, thus its method signature is equivalent to

def make[T]()(implicit e: ClassManifest[T]): ArrayBuilder[T]

Thus, the argument of implicitly is the same argument passed to make. And ClassManifests (or in Scala 2.10) ClassTags are normally not defined somewhere in the library, they are auto-generated by the compiler when a method expecting such a context bound is called.

Nader Aeinehchi

unread,
Nov 19, 2012, 4:17:28 PM11/19/12
to scala...@googlegroups.com
"make has a context bound"

Where is this context defined?

Thanks.

Simon Schäfer

unread,
Nov 19, 2012, 4:37:09 PM11/19/12
to scala...@googlegroups.com
Nowhere. As I said, for ClassManifest, it is compiler generated.

Juha Heljoranta

unread,
Nov 19, 2012, 4:57:31 PM11/19/12
to scala...@googlegroups.com, Nader Aeinehchi
These might help:
http://www.artima.com/pins1ed/implicit-conversions-and-parameters.html#21.5
http://stackoverflow.com/questions/6085085/why-cant-i-create-an-array-of-generic-type

Generic arrays like Array[T] can be bit annoying because the compiler
needs to know the exact type of the T. If you tell the compiler the
type explicitly, like String, then everything is ok. Otherwise the
compiler needs ClassTag/ClassManifest to figure out the type.

syntax:

def make[T: ClassManifest]() = ...

is officially called 'context bound' and is syntax sugar for

def make[T](implicit ev0: ClassManifest[T]) = ...

These examples might also help

def okA: ArrayBuilder[String] =
ArrayBuilder.make[String]()
def okB[T: ClassManifest]: ArrayBuilder[T] =
ArrayBuilder.make[T]()
def okC[T](implicit myCm: ClassManifest[T]): ArrayBuilder[T] =
ArrayBuilder.make[T]()
def okD[T](myCm: ClassManifest[T]): ArrayBuilder[T] = {
implicit val foo = myCm
ArrayBuilder.make[T]()
}

Cheers,
Juha

Nader Aeinehchi

unread,
Nov 22, 2012, 7:09:58 AM11/22/12
to scala...@googlegroups.com
Hi

Thanks to everyone for the help. 

For completness, please see the article by Martin Odersky about Context Bound as used in the new Array implementation.  Note that Context Bound is relatively new and not documented in the main Scala books.

http://www.scala-lang.org/sites/default/files/sids/cunei/Thu,%202009-10-01,%2013:54/arrays.pdf

See also:
http://stackoverflow.com/questions/4465948/what-are-scala-context-and-view-bounds

Naftoli Gugenheim

unread,
Nov 23, 2012, 1:34:01 AM11/23/12
to Nader Aeinehchi, scala-user

On Sun, Nov 18, 2012 at 10:08 AM, Nader Aeinehchi <na...@aeinehchi.com> wrote:
Where is the implicit "e" defined in order to be used in ArrayBuilder's "make" method?

In short: That depends on what T you call it with, and where you call it. For instance:

object O {
  implicit val i: Int = 10  // don't do this in real programs
  println(implicitly[Int]) // prints 10
}


Paolo Giarrusso

unread,
Nov 23, 2012, 10:22:06 AM11/23/12
to scala...@googlegroups.com
Il giorno giovedì 22 novembre 2012 13:09:58 UTC+1, Nader Aeinehchi ha scritto:
Hi

Thanks to everyone for the help. 

For completness, please see the article by Martin Odersky about Context Bound as used in the new Array implementation.  Note that Context Bound is relatively new and not documented in the main Scala books.

I have to disagree because they appear in _the_ Scala book [*]: Context bounds are described at page 582, Sec. 24.11, of Programming in Scala 2nd ed., and I found them in the analytic index. But I have to agree that they should get much more importance - view bounds, which are now so much out-of-fashion that they might be deprecated soon, have a whole subsection, so you still have a point.

[*] Disclaimer: I have not read any other Scala book except the Scala reference, so I can't really compare with them. But I can't remember a book which leads me from "no-clue-on-language-X" to such proficiency as this one, and which was so interesting from the beginning; especially, each feature is motivated extremely well. As a researcher, I can recognize the hand of a quite good paper author. I mean, it was so interesting to make me read it from cover to cover, and that's something I think that I didn't for years. Sorry for the fanatism.

Best regards
Reply all
Reply to author
Forward
0 new messages