- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
fun with function specialization
Tue, 2011-12-13, 17:18
Say you're Range.foreach and a Function1[Int, ?] is coming your way. Say,
(x: Int) => x + 1
There is a boxing-free implementation available to you, but it isn't this one:
public abstract void apply$mcVI$sp(int);
It's this one:
public abstract int apply$mcII$sp(int);
If you call the first one, where do you go? You get the default implementation:
public void apply$mcVI$sp(int);
0: aload_0
1: iload_1
2: invokestatic #1f1f1f; //Method
scala/Function1$class.apply$mcVI$sp:(Lscala/Function1;I)V
5: return
which calls
public static void apply$mcVI$sp(scala.Function1, int);
0: aload_0
1: iload_1
2: invokestatic #94; //Method
scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
5: invokeinterface #39, 2; //InterfaceMethod
scala/Function1.apply:(Ljava/lang/Object;)Ljava/lang/Object;
10: pop
11: return
In which case I've cleverly replaced boxing with boxing plus extra indirection!
I don't know how to do it without special-casing functions with
respect to specialization, but I think it would pay off to override
apply$mcV[IJDZ]$sp in specialized function1s, and have it call
whichever apply is actually being specialized, discarding the return
value. (Or just duplicate the specialized implementation.)
Tue, 2011-12-13, 18:11
#2
Re: Re: fun with function specialization
It's all more complicated than it should be, but why do we have a polymorphic foreach? Why not have foreach take only Int => Unit?
On Tue, Dec 13, 2011 at 5:38 PM, Paul Phillips <paulp@improving.org> wrote:
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
On Tue, Dec 13, 2011 at 5:38 PM, Paul Phillips <paulp@improving.org> wrote:
Or I guess in principle specializing Range.foreach on all the types
for which Function1's second parameter is specialized would address it
for Range. Unfortunately that takes us into the realm of composing
trait specialization with method specialization, not exactly our
paragon of robustness.
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
Tue, 2011-12-13, 18:21
#3
Re: Re: fun with function specialization
On 13 December 2011 17:00, iulian dragos <jaguarul@gmail.com> wrote:
It's all more complicated than it should be, but why do we have a polymorphic foreach? Why not have foreach take only Int => Unit?
I have always wondered this also. Perhaps this is because it would complicate the typechecker or some other gubbins to have the compiler choose between A => B and A => Unit more generally?
Matthew
On Tue, Dec 13, 2011 at 5:38 PM, Paul Phillips <paulp@improving.org> wrote:
Or I guess in principle specializing Range.foreach on all the types
for which Function1's second parameter is specialized would address it
for Range. Unfortunately that takes us into the realm of composing
trait specialization with method specialization, not exactly our
paragon of robustness.
--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais
--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster@gmail.com gchat: turingatemyhamster@gmail.commsn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143
Tue, 2011-12-13, 18:31
#4
Re: Re: fun with function specialization
On Tue, Dec 13, 2011 at 9:00 AM, iulian dragos wrote:
> It's all more complicated than it should be, but why do we have a
> polymorphic foreach? Why not have foreach take only Int => Unit?
Because it's inherited from TraversableLike and has to implement the
same signature.
Tue, 2011-12-13, 18:41
#5
Re: Re: fun with function specialization
Oh, you mean at all? It's because (as far as I know) otherwise you
couldn't pass anything but T => Unit methods to foreach. Anything
which returned any other type wouldn't typecheck; a T can be coerced
to Unit, but a T => U cannot be coerced to T => Unit.
Or I guess in principle specializing Range.foreach on all the types
for which Function1's second parameter is specialized would address it
for Range. Unfortunately that takes us into the realm of composing
trait specialization with method specialization, not exactly our
paragon of robustness.