Re: Why is Tuple only specialized for Int, Long and Double?

why aren't specializations compiled on demand (only when used in code or dynamically at runtime), and the annotations only represent possibilities?
this would solve all problems

-------- Original-Nachricht --------
> Datum: Fri, 30 Jul 2010 13:49:36 +0200
> Von: "David Flemström"
> An: Jesper de Jong , Scala User List
> Betreff: Re: [scala-user] Why is Tuple only specialized for Int, Long and Double?

> On Fri, Jul 30, 2010 at 1:36 PM, Jesper de Jong wrote:
> >
> > It would indeed be nice if at least the smaller tuples (maybe upto
> Tuple3)
> > would be @specialized for Int, Long, Float, Double.
>
> I understand that if you'd specialize Tuple10 on all eight primitive
> types,
> > you'd get 8^10 = 1,073,741,824 combinations which is impractical...
> >
> There are 9 primitive types in Scala:
>
> 1. Byte
> 2. Char
> 3. Short
> 4. Int
> 5. Long
> 6. Float
> 7. Double
> 8. Boolean
> 9. Unit
>
> Adding AnyRef to the list (because there have to exist specialization
> combinations like Foo[AnyRef, Int]) gives us 10 as the base of the
> exponential function, and Tuple10 would thus need 10 (american) billion
> classes.
>
> (By the way, added back the scala-user list as a recipient)

"Specialization is performed at the definition site in order to allow
separate compilation. If specialization was performed only at the
point where a generic class is instantiated to a primitive type, it
may be the case that the original class definition is not compiled in
the same run (this is the usual case, since we expect specialization
to play an important role in libraries) and the compiler cannot derive
specialized implementations for methods that might benefit from it."

http://www.scala-lang.org/sid/9

-jason

On Fri, Jul 30, 2010 at 3:21 PM, Dennis Haupt wrote:
> question:
> why aren't specializations compiled on demand (only when used in code or dynamically at runtime), and the annotations only represent possibilities?
> this would solve all problems
>
>
> -------- Original-Nachricht --------
>> Datum: Fri, 30 Jul 2010 13:49:36 +0200
>> Von: "David Flemström"
>> An: Jesper de Jong , Scala User List
>> Betreff: Re: [scala-user] Why is Tuple only specialized for Int, Long and     Double?
>
>> On Fri, Jul 30, 2010 at 1:36 PM, Jesper de Jong wrote:
>> >
>> > It would indeed be nice if at least the smaller tuples (maybe upto
>> Tuple3)
>> > would be @specialized for Int, Long, Float, Double.
>>
>> I understand that if you'd specialize Tuple10 on all eight primitive
>> types,
>> > you'd get 8^10 = 1,073,741,824 combinations which is impractical...
>> >
>> There are 9 primitive types in Scala:
>>
>>    1. Byte
>>    2. Char
>>    3. Short
>>    4. Int
>>    5. Long
>>    6. Float
>>    7. Double
>>    8. Boolean
>>    9. Unit
>>
>> Adding AnyRef to the list (because there have to exist specialization
>> combinations like Foo[AnyRef, Int]) gives us 10 as the base of the
>> exponential function, and Tuple10 would thus need 10 (american) billion
>> classes.
>>
>> (By the way, added back the scala-user list as a recipient)
>
> --
> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
>

This could be worked around by using JIT class generation, although I realise that this may be a little bit of a pain to set up - you'd have to push in an extra classloader to the JVM, or call some sort of initialisation method in main(). A specializing class loader that injects these specialised implementations would allow us to have exactly those classes that are needed from the potentially billions of possibilities. I assume that we could re-use all the code generation stuff that's already used in the compiler to do this.

Matthew

On 30 July 2010 14:34, Jason Zaugg <jzaugg@gmail.com> wrote:

"Specialization is performed at the definition site in order to allow
separate compilation. If specialization was performed only at the
point where a generic class is instantiated to a primitive type, it
may be the case that the original class definition is not compiled in
the same run (this is the usual case, since we expect specialization
to play an important role in libraries) and the compiler cannot derive
specialized implementations for methods that might benefit from it."

http://www.scala-lang.org/sid/9

-jason

This could work well. EXCEPT (and this is a big one) it would not work in any of the following situations:

* Java applets (including JavaFX)
* Android
* JavaME
* Any other VM environment where you are running in a security context.

-Arthur


On Fri, Jul 30, 2010 at 11:22 AM, Matthew Pocock <turingatemyhamster@gmail.com> wrote:

This could be worked around by using JIT class generation, although I realise that this may be a little bit of a pain to set up - you'd have to push in an extra classloader to the JVM, or call some sort of initialisation method in main(). A specializing class loader that injects these specialised implementations would allow us to have exactly those classes that are needed from the potentially billions of possibilities. I assume that we could re-use all the code generation stuff that's already used in the compiler to do this.

Matthew

On 30 July 2010 14:34, Jason Zaugg <jzaugg@gmail.com> wrote:

"Specialization is performed at the definition site in order to allow
separate compilation. If specialization was performed only at the
point where a generic class is instantiated to a primitive type, it
may be the case that the original class definition is not compiled in
the same run (this is the usual case, since we expect specialization
to play an important role in libraries) and the compiler cannot derive
specialized implementations for methods that might benefit from it."

http://www.scala-lang.org/sid/9

-jason