- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Issue with specialization
Mon, 2011-12-05, 18:27
Hello all,
So in some spare time, I started working on a Array class with unboxed higher-order-functions.I have come across the following issue when using specialization though. It is demonstrated in the following two gists:
Boxinghttps://gist.github.com/1425438
Noboxing (generates all possible specialized versions for Function1https://gist.github.com/1434304
The core issue is that if we have a class with a specialized parameter T andthen a method with a specialized parameter W, the compiler does not seemto be generated the cross product of possibilities for the specialized method requiredfor a Function1[T,W]. (It does generate specialized methods if you use a Function1[T,T] though...)
When both specialized type parameters are in the method definition, the compiler is doingthe right thing and generated methods for all possible specialized input and output(and calling the correct specialized version of Function1).
The issue here is that the class I want to write is something like
class MArray[@specialized T](array:Array[T]) { def map[@speciazlized W](f:Function[T,W]):Array[W]}
we will still box.
Am I being silly or doing something stupid? Or is this a bug?
As always, advice is greatly appreciated.
marc
So in some spare time, I started working on a Array class with unboxed higher-order-functions.I have come across the following issue when using specialization though. It is demonstrated in the following two gists:
Boxinghttps://gist.github.com/1425438
Noboxing (generates all possible specialized versions for Function1https://gist.github.com/1434304
The core issue is that if we have a class with a specialized parameter T andthen a method with a specialized parameter W, the compiler does not seemto be generated the cross product of possibilities for the specialized method requiredfor a Function1[T,W]. (It does generate specialized methods if you use a Function1[T,T] though...)
When both specialized type parameters are in the method definition, the compiler is doingthe right thing and generated methods for all possible specialized input and output(and calling the correct specialized version of Function1).
The issue here is that the class I want to write is something like
class MArray[@specialized T](array:Array[T]) { def map[@speciazlized W](f:Function[T,W]):Array[W]}
we will still box.
Am I being silly or doing something stupid? Or is this a bug?
As always, advice is greatly appreciated.
marc
Mon, 2011-12-05, 20:17
#2
Re: Issue with specialization
On Mon, Dec 05, 2011 at 09:27:17AM -0800, marc wrote:
> The core issue is that if we have a class with a specialized parameter T and
> then a method with a specialized parameter W, the compiler does not seem
> to be generated the cross product of possibilities for the specialized
> method required
> for a Function1[T,W]. (It does generate specialized methods if you use a
> Function1[T,T] though...)
Thanks for catching this! In retrospect, I think I may have been
affected by this problem before but not identified the cause.
I wonder how hard it will be to fix? I've CC'd Aleksander Prokopec who
(last I knew) was working on the specialization code.
Mon, 2011-12-05, 22:27
#3
Re: Issue with specialization
After some talk on twitter, a bug has been filed herehttps://issues.scala-lang.org/browse/SI-5281
Mon, 2011-12-05, 22:57
#4
Re: Issue with specialization
I think this is the beginnings of a workaround...
https://gist.github.com/1435472
Also, I am trying to understand the warning:"class F1 must be a trait. Specialized version of class F12D will inherit generic marc.junk.F1[Unit,Double]”
https://gist.github.com/1435472
Also, I am trying to understand the warning:"class F1 must be a trait. Specialized version of class F12D will inherit generic marc.junk.F1[Unit,Double]”
Mon, 2011-12-05, 23:07
#5
Re: Re: Issue with specialization
On Mon, Dec 05, 2011 at 01:43:50PM -0800, marc wrote:
> Also, I am trying to understand the warning:
> "class F1 must be a trait. Specialized version of class F12D will inherit
> generic marc.junk.F1[Unit,Double]”
The error is pretty much what it sounds like. It's asking you to use a
trait instead of an abstract class.
I can't find a good link at the moment, but the reason is that
specialization doesn't interact well with subtyping. That is, with:
class Foo[@specialized T] { ... }
class Bar[@specialized T] extends Foo[T] { ... }
In this case the specialized Bar classes will inherit from the generic
(non-specialized) Foo. This preserves some inheritance assumptions and
is tied to the implementation. However:
trait Foo[@specialized T] { ... }
class Bar[@specialized T] extends Foo[T] { ... }
will work as you expect.
Mon, 2011-12-05, 23:37
#6
Re: Re: Issue with specialization
Thanks, I figured that out eventually. Had issues at first as traits do not support views.
Tue, 2012-01-10, 16:31
#7
Specialization
Dear all,is it possible to specialize PartialFunction[Int,Double] or one should create an equivalent trait specialized for Int and Double?
Best Regards
Edmondo
Best Regards
Edmondo
Tue, 2012-01-10, 17:41
#8
Re: Specialization
PartialFunction is not presently specialized; you should create your own class that has the functionality you need (which may or may not be identical to that of PartialFunction).
--Rex
On Tue, Jan 10, 2012 at 10:14 AM, Edmondo Porcu <edmondo.porcu@gmail.com> wrote:
--Rex
On Tue, Jan 10, 2012 at 10:14 AM, Edmondo Porcu <edmondo.porcu@gmail.com> wrote:
Dear all,is it possible to specialize PartialFunction[Int,Double] or one should create an equivalent trait specialized for Int and Double?
Best Regards
Edmondo
I should add, I am working with scala 2.9.1-final.