Function2: "our not-so-special little guy"

[Paul Phillips]

Now that Erik has gotten AnyRef specialization working tolerably well, I looked at specializing Function2 on AnyRef and Boolean (knowing that was likely to be too much.) OK, that's quite a bit:

% git diff head^ --diff-filter=A --name-only |wc -l

     654

654 new classfiles.  Except:

% git diff head^ --diff-filter=A --name-only |egrep -v '(tupled|curried|andThen)' |wc -l 

     240

Only 240 of those are the ones I'm after (more like 120, but I expect to eat the interface/implclass hit.) And 414 are "unluckily positioned accident."

Those functions are not entirely unuseful, but they're sure not this kind of useful.  There's a little chicken/egg here because a lot of us don't use them for performance reasons, and I guess explosively specializing them might help with that.  But even in the best case that chicken is godzilla and the egg wouldn't feed a small family of lizards.

Two things to do, both of which make sense to me independently of whether we want to specialize F2 any further and independently of one another.

 - @nospecialize annotation for members (no reason we can't do this that I can think of... am I missing one?)

 - move those methods out of the instances

I know it bothers our object-oriented purity to have tupled and curried in a separate object, but this way has been all lose: the huge specialization tax, and we weren't even able to get rid of the ones on the object because type inference doesn't work as well on the instance, as seen here.

  http://stackoverflow.com/questions/2354277/function-tupled-and-placeholder-syntax

[martin odersky]

100+. We need to better control the effects of specialization. In
particular, do something about tupled and curried. Moving to an
implicit decorator or @nospecialize seem both valid options.

Martin

--
Martin Odersky
Prof., EPFL and Chairman, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967

[Paul Phillips]

On Sun, Feb 19, 2012 at 12:58 PM, martin odersky <martin....@epfl.ch> wrote:

100+. We need to better control the effects of specialization. In
particular, do something about tupled and curried. Moving to an
implicit decorator or @nospecialize seem both valid options.

 Okay, while we're on the subject here's another I just opened.

-- pasted from SI-5507 --

Can we avoid generating "V" specializations in parameter positions? I acknowledge this may be necessary for reasons which my grasp of the possibilities does not make me aware of.  However, consider the substantial impact this small sounding change has.

final class Foo[@specialized T1, @specialized T2, @specialized R](f: (T1, T2) => R) { }

Right now that generates 10*10*10 = 1000 extra classfiles.  If it skipped Unit for T1 and T2, which are completely useless because Unit erases to BoxedUnit and T1 and T2 are already specialized on AnyRef, then it would generate 9*9*10 = 810 classfiles, a 19% reduction.  Or flipped around, we're eating an almost 25% size gain for nothing.

One can of course enumerate the types (or make one of my fancy new groups in the Specializable companion) but the point of the ticket is that it would be even better if we didn't have to tell the compiler that we don't need 25% more custom code to handle all the incoming Units we intend on processing.

[martin odersky]

On Sun, Feb 19, 2012 at 10:18 PM, Paul Phillips <pa...@improving.org> wrote:
>
> On Sun, Feb 19, 2012 at 12:58 PM, martin odersky <martin....@epfl.ch>
> wrote:
>>
>> 100+. We need to better control the effects of specialization. In
>> particular, do something about tupled and curried. Moving to an
>> implicit decorator or @nospecialize seem both valid options.
>
>
>  Okay, while we're on the subject here's another I just opened.
>
> -- pasted from SI-5507 --
>
> Can we avoid generating "V" specializations in parameter positions? I
> acknowledge this may be necessary for reasons which my grasp of the
> possibilities does not make me aware of.

I do not see a reason why not, actually.

-- Martin

 However, consider the substantial
> impact this small sounding change has.
>
> final class Foo[@specialized T1, @specialized T2, @specialized R](f: (T1,
> T2) => R) { }
>
> Right now that generates 10*10*10 = 1000 extra classfiles.  If it skipped
> Unit for T1 and T2, which are completely useless because Unit erases to
> BoxedUnit and T1 and T2 are already specialized on AnyRef, then it would
> generate 9*9*10 = 810 classfiles, a 19% reduction.  Or flipped around, we're
> eating an almost 25% size gain for nothing.
>
> One can of course enumerate the types (or make one of my fancy new groups in
> the Specializable companion) but the point of the ticket is that it would be
> even better if we didn't have to tell the compiler that we don't need 25%
> more custom code to handle all the incoming Units we intend on processing.

--

[Erik Osheim]

On Sun, Feb 19, 2012 at 09:58:18PM +0100, martin odersky wrote:
> 100+. We need to better control the effects of specialization. In
> particular, do something about tupled and curried. Moving to an
> implicit decorator or @nospecialize seem both valid options.

It might also be good to have the reverse of @nospecialize, i.e. a way
to force specialization on methods whose type signatures don't
immediately suggest specialization.

Here's an example:

import scala.{specialized => spec}

class Foo[@spec A](a1:A, a2:A) {
def isEqual:Boolean = a1 == a2

class Bar[@spec B](b:B) {
def allEqual = a1 == b && a2 == b
}
}

Here, "isEqual" isn't specialized because the method's arguments and
return type don't mention A. "Bar" is only specialized on B currently,
but even if the class was also specialized on A its "allEqual" method
likely would not be.

Users who write code like this probably expect specialization to copy
*all* methods, and are surprised to find out that they are not, but
that adding an unused parameter of type A to a method *will* cause
scalac to create a specialized overload of that method.

An explicit annotation would probably be easier to reason about in the
long run (assuming a larger refactor along the lines of my previous
proposal [1] isn't taken).

-- Erik

[1] http://groups.google.com/group/scala-debate/browse_thread/thread/94c2ae2daaaa2136

[iulian dragos]

On Sun, Feb 19, 2012 at 9:48 PM, Paul Phillips <pa...@improving.org> wrote:

Now that Erik has gotten AnyRef specialization working tolerably well, I looked at specializing Function2 on AnyRef and Boolean (knowing that was likely to be too much.) OK, that's quite a bit:

What does AnyRef specialization buy us? I thought it's only useful when dealing with generic arrays.

iulian

 

% git diff head^ --diff-filter=A --name-only |wc -l

     654

654 new classfiles.  Except:

% git diff head^ --diff-filter=A --name-only |egrep -v '(tupled|curried|andThen)' |wc -l 

     240

Only 240 of those are the ones I'm after (more like 120, but I expect to eat the interface/implclass hit.) And 414 are "unluckily positioned accident."

Those functions are not entirely unuseful, but they're sure not this kind of useful.  There's a little chicken/egg here because a lot of us don't use them for performance reasons, and I guess explosively specializing them might help with that.  But even in the best case that chicken is godzilla and the egg wouldn't feed a small family of lizards.

Two things to do, both of which make sense to me independently of whether we want to specialize F2 any further and independently of one another.

 - @nospecialize annotation for members (no reason we can't do this that I can think of... am I missing one?)

 - move those methods out of the instances

I know it bothers our object-oriented purity to have tupled and curried in a separate object, but this way has been all lose: the huge specialization tax, and we weren't even able to get rid of the ones on the object because type inference doesn't work as well on the instance, as seen here.

  http://stackoverflow.com/questions/2354277/function-tupled-and-placeholder-syntax

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Erik Osheim]

On Wed, Feb 22, 2012 at 07:49:55PM +0100, iulian dragos wrote:
> What does AnyRef specialization buy us? I thought it's only useful when
> dealing with generic arrays.

(As far as I know) without AnyRef specialization you can't mix AnyRef
and AnyVal types without causing boxing. For instance, Function1[Foo,
Int] will be able to use the Function1$mcLI$sp implementation if
Function1 is compiled with AnyRef specialization, but otherwise it will
have to just use Function1 (which will box the return value).

This is what I've always understood the benefit of AnyRef
specialization to be.

-- Erik

[Aleksandar Prokopec]

True. I haven't considered that, having focused on the array indexing
performance instead.

--
Aleksandar Prokopec,
Doctoral Assistant
LAMP, IC, EPFL
http://people.epfl.ch/aleksandar.prokopec

[Ismael Juma]

On Wed, Feb 22, 2012 at 7:05 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

This is what I've always understood the benefit of AnyRef

specialization to be.

Me too.

Ismael

[iulian dragos]

Thanks for clarifying it!

iulian

 

-- Erik

[Paul Phillips]

On Wed, Feb 22, 2012 at 11:05 AM, Erik Osheim <er...@plastic-idolatry.com> wrote:

This is what I've always understood the benefit of AnyRef
specialization to be.

That's the benefit as understood by the guy who inflicted it on you too.  It was sufficiently surprising that it already inspired a ticket:

  https://issues.scala-lang.org/browse/SI-5512

 "Compiler generate one extraneous apply method for anonymous function returning a Java primitive type."

From which I will steal my comment for further elaboration:

--

This is a consequence of specializing Function1 on AnyRef.  If you look more closely you will see that the function is indeed called.  It is part of the interface and called from the superclass AbstractFunction1$mcIL$sp. (Before specializing on AnyRef, the superclass was AbstractFunction1.)

Here is a sanitized bytecode diff.  The parts other than the new method are the important ones.

{code}

-public final class AnonFun$$anonfun$f$## extends scala.runtime.AbstractFunction1 implements scala.Serializable{

+public final class AnonFun$$anonfun$f$## extends scala.runtime.AbstractFunction1$mcIL$sp implements scala.Serializable{

 public static final long serialVersionUID;

   Signature: J

 

@@ -29,10 +29,18 @@ public final java.lang.Object apply(java.lang.Object);

 ##:    invokestatic    ###; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;

 ##:    areturn

 

+public final int apply(java.lang.Object);

+  Signature: (Ljava/lang/Object;)I

+  Code:

+##:    aload_1

+##:    checkcast       ###; //class java/lang/String

+##:    invokevirtual   ###; //Method apply:(Ljava/lang/String;)I

+##:    ireturn

+

 public AnonFun$$anonfun$f$##(AnonFun);

   Signature: (LAnonFun;)V

   Code:

-##:    invokespecial   ###; //Method scala/runtime/AbstractFunction1."<init>":()V

+##:    invokespecial   ###; //Method scala/runtime/AbstractFunction1$mcIL$sp."<init>":()V

 ##:    return

 

 }

{code}

[Vlad Ureche]

On Mon, Feb 20, 2012 at 7:42 AM, Erik Osheim <er...@plastic-idolatry.com> wrote:

On Sun, Feb 19, 2012 at 09:58:18PM +0100, martin odersky wrote:
> 100+. We need to better control the effects of specialization. In
> particular, do something about tupled and curried. Moving to an
> implicit decorator or @nospecialize seem both valid options.

It might also be good to have the reverse of @nospecialize, i.e. a way
to force specialization on methods whose type signatures don't
immediately suggest specialization.

I also like this suggestion. It would give the users better control over what gets specialized.

And I've been giving some thought to Matthew Pocock's idea of controling the specialization to avoid generating the full cartesian product of all specializations. My take on it would be to add a @specializedOn annotation to control the types we want to specialize on. The notation is clearly on the heavyweight side, so any ideas on how to make it less verbose are welcome:

@specializeOn(Int, Int)
@specializeOn(Int, Unit)
@specializeOn(Int, AnyRef)
/* same for Boolean, Float and Double */
@specializeOn(AnyRef, Unit)
@specializeOn(Int, Bool)
@specializeOn(Float, Bool)
@specializeOn(Double, Bool)
trait Function1[@specialized -T1, @specialized +R] extends AnyRef

I guess with 16 specialized classes we could get most of the cases of Function1 (currently Function1 generates 35 specialized classes)
Unfortunately this notation, as it is, wouldn't scale to Function2, so we need to make it leaner.

Back to exploring the idea itself, regardless of the syntax, I would suggest being able to add something like:
  @specialized(Int, Any)
which provides a safety net if none of the specialized cases ((Int,Int), (Int, Unit), (Int, AnyRef), (Int, Bool)) match the type parameters, This would only specialize on the first argument, leaving the second one boxed. It's only a partial solution, but it would cut some of the boxing/unboxing time without generating 10 classes. (e.g. Function1[Int, Byte] would match the (Int, Any) specialization, keeping Int unboxed but boxing Byte)

What do you think?

Vlad

[iulian dragos]

On Thu, Feb 23, 2012 at 12:41 PM, Vlad Ureche <vlad....@gmail.com> wrote:

On Mon, Feb 20, 2012 at 7:42 AM, Erik Osheim <er...@plastic-idolatry.com> wrote:

On Sun, Feb 19, 2012 at 09:58:18PM +0100, martin odersky wrote:
> 100+. We need to better control the effects of specialization. In
> particular, do something about tupled and curried. Moving to an
> implicit decorator or @nospecialize seem both valid options.

It might also be good to have the reverse of @nospecialize, i.e. a way
to force specialization on methods whose type signatures don't
immediately suggest specialization.

I also like this suggestion. It would give the users better control over what gets specialized.

And I've been giving some thought to Matthew Pocock's idea of controling the specialization to avoid generating the full cartesian product of all specializations. My take on it would be to add a @specializedOn annotation to control the types we want to specialize on. The notation is clearly on the heavyweight side, so any ideas on how to make it less verbose are welcome:

Not sure if it helps with all use-cases, but 'specialized' could allow also the names of type parameters that are in scope? (I know, types can't be used as terms, but something along these lines..)

Or, have both specializedOn and 'dontSpecializeOn', choosing which way it's easier to describe.

iulian

 

@specializeOn(Int, Int)
@specializeOn(Int, Unit)
@specializeOn(Int, AnyRef)
/* same for Boolean, Float and Double */
@specializeOn(AnyRef, Unit)
@specializeOn(Int, Bool)
@specializeOn(Float, Bool)
@specializeOn(Double, Bool)
trait Function1[@specialized -T1, @specialized +R] extends AnyRef

I guess with 16 specialized classes we could get most of the cases of Function1 (currently Function1 generates 35 specialized classes)
Unfortunately this notation, as it is, wouldn't scale to Function2, so we need to make it leaner.

Back to exploring the idea itself, regardless of the syntax, I would suggest being able to add something like:
  @specialized(Int, Any)
which provides a safety net if none of the specialized cases ((Int,Int), (Int, Unit), (Int, AnyRef), (Int, Bool)) match the type parameters, This would only specialize on the first argument, leaving the second one boxed. It's only a partial solution, but it would cut some of the boxing/unboxing time without generating 10 classes. (e.g. Function1[Int, Byte] would match the (Int, Any) specialization, keeping Int unboxed but boxing Byte)

What do you think?

Vlad

[Matthew Pocock]

On 23 February 2012 11:41, Vlad Ureche <vlad....@gmail.com> wrote:

@specializeOn(Int, Int)

@specializeOn(Int, Unit)
@specializeOn(Int, AnyRef)
/* same for Boolean, Float and Double */
@specializeOn(AnyRef, Unit)
@specializeOn(Int, Bool)
@specializeOn(Float, Bool)
@specializeOn(Double, Bool)
trait Function1[@specialized -T1, @specialized +R] extends AnyRef

 

What do you think?

I'm waiting for someone to point out that we are straying close to defining a type-level indicator function over tuples of types that should be specialized on, and to come up with some type-class skulduggery that does the trick in an entirely incomprehensible but elegant way, possibly by co-opting a macro or some other bleeding edge functionality to bind types and type-names from the specialized signature to those appearing in the annotation.

@specializeOn(MyIndicatorTypeClass[T1, R])

trait Function1[@specialized -T1, @specialized +R] extends AnyRef

Matthew

 

Vlad

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143

[Paul Phillips]

On Thu, Feb 23, 2012 at 5:50 AM, Matthew Pocock <turingate...@gmail.com> wrote:

I'm waiting for someone to point out that we are straying close to defining a type-level indicator function over tuples of types that should be specialized on, and to come up with some type-class skulduggery that does the trick in an entirely incomprehensible but elegant way, possibly by co-opting a macro or some other bleeding edge functionality to bind types and type-names from the specialized signature to those appearing in the annotation.

And I'm waiting for someone to point out... oh I should know better.  The real trick was doing this without adding a type parameter to @specialized.

(Notice that you could as easily say new Group[(Int, Char, Double)](null), and were I not trying for seamlessness with @specialized, lose the unnecessary parameter and just give the types: tuples as type-varargs.)

https://github.com/scala/scala/commit/bb23d766bc

object Specializable {
  // No type parameter in @specialized annotation.
  trait SpecializedGroup { }
  
  // Smuggle a list of types by way of a tuple upon which Group is parameterized.
  class Group[T >: Null](value: T) extends SpecializedGroup { }

  final val Primitives  = new Group(Byte, Short, Int, Long, Char, Float, Double, Boolean, Unit)
  final val Everything  = new Group(Byte, Short, Int, Long, Char, Float, Double, Boolean, Unit, AnyRef)
  final val Bits32AndUp = new Group(Int, Long, Float, Double)
  final val Integral    = new Group(Byte, Short, Int, Long, Char)
  final val AllNumeric  = new Group(Byte, Short, Int, Long, Char, Float, Double)
  final val BestOfBreed = new Group(Int, Double, Boolean, Unit, AnyRef)
}

/** Annotate type parameters on which code should be automatically
 *  specialized. For example:
 *  {{{
 *    class MyList[@specialized T] ...
 *  }}}
 *
 *  Type T can be specialized on a subset of the primitive types by
 *  specifying a list of primitive types to specialize at:
 *  {{{
 *    class MyList[@specialized(Int, Double, Boolean) T] ..
 *  }}}
 *
 *  @since 2.8
 */
// class tspecialized[T](group: Group[T]) extends annotation.StaticAnnotation {
 
class specialized(group: SpecializedGroup) extends annotation.StaticAnnotation {
  def this(types: Specializable*) = this(new Group(types.toList))
  def this() = this(Everything)
}

... compiler ...

  private def specializedOn(sym: Symbol): List[Symbol] = {
    sym getAnnotation SpecializedClass match {
      case Some(AnnotationInfo(_, Nil, _)) => specializableTypes.map(_.typeSymbol)
      case Some(ann @ AnnotationInfo(_, args, _)) => {
        args map (_.tpe) flatMap { tp =>
          tp baseType GroupOfSpecializable match {
            case TypeRef(_, GroupOfSpecializable, arg :: Nil) =>
              arg.typeArgs map (_.typeSymbol)
            case _ => 
              List(tp.typeSymbol)
          }
        }
      }
      case _ => Nil
    }
  }

[Paul Phillips]

On Thu, Feb 23, 2012 at 3:41 AM, Vlad Ureche <vlad....@gmail.com> wrote:

Back to exploring the idea itself, regardless of the syntax, I would suggest being able to add something like:
  @specialized(Int, Any)
which provides a safety net if none of the specialized cases ((Int,Int), (Int, Unit), (Int, AnyRef), (Int, Bool)) match the type parameters, This would only specialize on the first argument, leaving the second one boxed. It's only a partial solution, but it would cut some of the boxing/unboxing time without generating 10 classes. (e.g. Function1[Int, Byte] would match the (Int, Any) specialization, keeping Int unboxed but boxing Byte)

I hadn't thought about this - you're right, we're blowing it here.  But can't we just be smarter about dispatch, and use AnyRef? Any feels superfluous.  It's the opposite of special!

In the below, why not have g1 call apply$mcLI$sp like g2 does?

class A {

  def f1: Int => Byte = ???

  def f2: Int => AnyRef = ???

  def g1 = f1(5)

  def g2 = f2(5)

}

public byte g1();

   5: invokestatic #31; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;

   8: invokeinterface #37,  2; //InterfaceMethod scala/Function1.apply:(Ljava/lang/Object;)Ljava/lang/Object;

   13: invokestatic #41; //Method scala/runtime/BoxesRunTime.unboxToByte:(Ljava/lang/Object;)B

   16: ireturn

public java.lang.Object g2();

   5: invokeinterface #49,  2; //InterfaceMethod scala/Function1.apply$mcLI$sp:(I)Ljava/lang/Object;

   10: areturn

[Erik Osheim]

On Thu, Feb 23, 2012 at 07:01:53AM -0800, Paul Phillips wrote:
> I hadn't thought about this - you're right, we're blowing it here. But
> can't we just be smarter about dispatch, and use AnyRef? Any feels
> superfluous. It's the opposite of special!

Agreed, it seems like we should be able to do this. I'm not sure how
many assumptions this violates but it's certainly worth looking into.

I guess we should open a ticket?

-- Erik

[Vlad Ureche]

On Thu, Feb 23, 2012 at 3:17 PM, Paul Phillips <pa...@improving.org> wrote:

And I'm waiting for someone to point out... oh I should know better.  The real trick was doing this without adding a type parameter to @specialized.

(Notice that you could as easily say new Group[(Int, Char, Double)](null), and were I not trying for seamlessness with @specialized, lose the unnecessary parameter and just give the types: tuples as type-varargs.)

That's cool, I haven't seen that patch. I think we could further reduce this by introducing two notations extending group:

@specializeOn(Group(Int, Boolean, Float, Double), SameAs(1))          /* meaning the second parameter should be the same as the first parameter */
@specializeOn(Group(Int, Boolean, Float, Double), FewerBytes(1))     /* meaning for Int, it would do: Short, Char, Byte, Boolean, Unit */

with these notations, plus a little patch I will commit in a few moments, the specialization for Function 1 will look like:

@specializeOn((Int, Boolean, Float, Double), (Unit, AnyRef, Boolean, Mirror(1), FewerBytes(1)))
@specializeOn(AnyRef, (Int, Boolean, Float, Double, Unit))

trait Function1[@specialized -T1, @specialized +R] extends AnyRef

What do you think?

On Thu, Feb 23, 2012 at 4:36 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:

Agreed, it seems like we should be able to do this. I'm not sure how
many assumptions this violates but it's certainly worth looking into.

I guess we should open a ticket?

Yep, that would be great!



Cheers,
Vlad

[Paul Phillips]

On Thu, Feb 23, 2012 at 9:05 AM, Vlad Ureche <vlad....@gmail.com> wrote:
> @specializeOn(Group(Int, Boolean, Float, Double), SameAs(1))          /*
> meaning the second parameter should be the same as the first parameter */
> @specializeOn(Group(Int, Boolean, Float, Double), FewerBytes(1))     /*
> meaning for Int, it would do: Short, Char, Byte, Boolean, Unit */

Wonderful idea. It would be a huge improvement to be able to express
the types in terms of other types. I noticed right away that simply
being able to enumerate a list of types was insufficient, in part
because it's so hard to give a meaningful name to a subset of types.
(Thus my not-really-serious names like "BestOfBreed".) Relative to
another group, that's where the meaningful names are.

[Paul Phillips]

On Thu, Feb 23, 2012 at 7:36 AM, Erik Osheim <er...@plastic-idolatry.com> wrote:
> Agreed, it seems like we should be able to do this. I'm not sure how
> many assumptions this violates but it's certainly worth looking into.

Perhaps I am being dense, but what assumptions could be violated? It
has been statically typed as an Int => Byte. There is an Object =>
Object point of entry and a specialized Int => Object point of entry,
and if either of those is called with anything other than a (possibly
boxed) Int or expecting anything other than a (possibly boxed) Byte,
all is lost because the type system failed. It better be true that we
can call the Int => Object interface and unbox a Byte.

There's only one implementation, it's just a question of how we get
there. We pick up the train midtown instead of riding all the way
from downtown.

[Erik Osheim]

On Thu, Feb 23, 2012 at 10:22:43AM -0800, Paul Phillips wrote:
> Perhaps I am being dense, but what assumptions could be violated? It
> has been statically typed as an Int => Byte. There is an Object =>
> Object point of entry and a specialized Int => Object point of entry,
> and if either of those is called with anything other than a (possibly
> boxed) Int or expecting anything other than a (possibly boxed) Byte,
> all is lost because the type system failed. It better be true that we
> can call the Int => Object interface and unbox a Byte.
>
> There's only one implementation, it's just a question of how we get
> there. We pick up the train midtown instead of riding all the way
> from downtown.

Oh, I don't think there's a conceptual problem. I just meant the amount
of code that would need to change in the implementation to support the
fact that a type parameter bound to an AnyVal type could choose to use
the AnyRef specialization.

To be clear: we should do this. :)

-- Erik