@specialized arguments

Martin reminded me that scala supports infix types, which could be used tosolve this beautifully:
trait |[A,B]class specialized[T] extends StaticAnnotationclass MyList[@specialized T]                                 // specialize on all class MyList[@specialized[Boolean | Int | Float] T]
the annotation tree can be easily decoded, it looks like                      AppliedTypeTree(                        Ident("$bar"),                         List(                          AppliedTypeTree(                            Ident("$bar"),                            List(                              Ident("Boolean"),                               Ident("Int")                            )                          ),                          Ident("Float")                        )                       )
the only thing you can't do is define the default type argumentsusing an auxiliary constructor or default type arguments :-)
Lukas

On Fri, Jun 19, 2009 at 18:53, Paul Phillips <paulp@improving.org> wrote:

Passing a string representing a sequence of types to an annotation seems
dicey - now two distinct components are outside the regular type system.

 class specialized(types: String)
 def this() { this("Boolean, Byte, Short, Char, Int, Long, Float, Double") }

Can this not take class objects or something? val BYTE = classOf[Byte]
and etc. in Predef or thte like could make it just as concise to use.

--
Paul Phillips      | Those who can make you believe absurdities
Imperfectionist    | can make you commit atrocities.
Empiricist         |     -- Voltaire
all hip pupils!    |----------* http://www.improving.org/paulp/ *----------

On Jul 3, 2009, at 9:47 AM, Lukas Rytz wrote:

> Martin reminded me that scala supports infix types, which could be
> used to
> solve this beautifully:
>
> trait |[A,B]
> class specialized[T] extends StaticAnnotation
> class MyList[@specialized T] //
> specialize on all
> class MyList[@specialized[Boolean | Int | Float] T]

Wonderful! I think we have a winner :)

iulian

>
> the annotation tree can be easily decoded, it looks like
> AppliedTypeTree(
> Ident("$bar"),
> List(
> AppliedTypeTree(
> Ident("$bar"),
> List(
> Ident("Boolean"),
> Ident("Int")
> )
> ),
> Ident("Float")
> )
> )
>
> the only thing you can't do is define the default type arguments
> using an auxiliary constructor or default type arguments :-)
>
> Lukas
>
>
> On Fri, Jun 19, 2009 at 18:53, Paul Phillips
> wrote:
> Passing a string representing a sequence of types to an annotation
> seems
> dicey - now two distinct components are outside the regular type
> system.
>
> class specialized(types: String)
> def this() { this("Boolean, Byte, Short, Char, Int, Long, Float,
> Double") }
>
> Can this not take class objects or something? val BYTE = classOf[Byte]
> and etc. in Predef or thte like could make it just as concise to use.
>
> --
> Paul Phillips | Those who can make you believe absurdities
> Imperfectionist | can make you commit atrocities.
> Empiricist | -- Voltaire
> all hip pupils! |----------* http://www.improving.org/paulp/
> *----------
>

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos

Lukas Rytz wrote:
> Martin reminded me that scala supports infix types, which could be
> used to
> solve this beautifully:
>
> trait |[A,B]
> class specialized[T] extends StaticAnnotation
> class MyList[@specialized T] //
> specialize on all
> class MyList[@specialized[Boolean | Int | Float] T]
This is a massive improvement over parsing a string! Can it be done so
that the | trait:

a) Doesn't need to be imported;
*and*
b) Isn't visible by default outside the @specialized context? :)

-0xe1a

Isn't specialization only interesting for types of AnyVal anyway? And if so, is this needed?

On Fri, Jul 3, 2009 at 12:42 PM, Alex Cruise <alex@cluonflux.com> wrote:

Lukas Rytz wrote:

Martin reminded me that scala supports infix types, which could be used to
solve this beautifully:

trait |[A,B]
class specialized[T] extends StaticAnnotation
class MyList[@specialized T]                                 // specialize on all
class MyList[@specialized[Boolean | Int | Float] T]

This is a massive improvement over parsing a string!  Can it be done so that the | trait:

a) Doesn't need to be imported;
*and*
b) Isn't visible by default outside the @specialized context? :)

-0xe1a

Indeed, specialization is interesting only for primitive types. The
question was how to specify what types should be considered, if for
some reason you'd not want all 8 of them. The bar type is simply a
nice syntax for putting together a list of types.

iulian

On Jul 7, 2009, at 5:36 PM, Nils Kilden-Pedersen wrote:

> Isn't specialization only interesting for types of AnyVal anyway?
> And if so, is this needed?
>
> On Fri, Jul 3, 2009 at 12:42 PM, Alex Cruise
> wrote:
> Lukas Rytz wrote:
> Martin reminded me that scala supports infix types, which could be
> used to
> solve this beautifully:
>
> trait |[A,B]
> class specialized[T] extends StaticAnnotation
> class MyList[@specialized T] //
> specialize on all
> class MyList[@specialized[Boolean | Int | Float] T]
> This is a massive improvement over parsing a string! Can it be done
> so that the | trait:
>
> a) Doesn't need to be imported;
> *and*
> b) Isn't visible by default outside the @specialized context? :)
>
> -0xe1a
>

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos

On Jul 3, 2009, at 7:42 PM, Alex Cruise wrote:

> Lukas Rytz wrote:
>> Martin reminded me that scala supports infix types, which could be
>> used to
>> solve this beautifully:
>>
>> trait |[A,B]
>> class specialized[T] extends StaticAnnotation
>> class MyList[@specialized T] //
>> specialize on all
>> class MyList[@specialized[Boolean | Int | Float] T]
> This is a massive improvement over parsing a string! Can it be done
> so
> that the | trait:
>
> a) Doesn't need to be imported;
> *and*
> b) Isn't visible by default outside the @specialized context? :)

Not without changing the language rules. But I see no major
inconvenience in having to import it (and neither having it in the
'scala' package, but I'm sure some people would like to define this
wonderful name for their own purposes).

iulian

>
> -0xe1a

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos

2009/7/8 Iulian Dragos <iulian.dragos@epfl.ch>

Indeed, specialization is interesting only for primitive types. The question was how to specify what types should be considered, if for some reason you'd not want all 8 of them.

Is there really a use case where you're only interested in specialization for certain primitives, but not for others? I guess so, but it seems weird to me.

Nils~

I could easily see wanting to specialize for long and double, but not
int, float, byte, or char.

Matt

On Wed, Jul 8, 2009 at 11:03 PM, Nils Kilden-Pedersen wrote:
> 2009/7/8 Iulian Dragos
>>
>> Indeed, specialization is interesting only for primitive types. The
>> question was how to specify what types should be considered, if for some
>> reason you'd not want all 8 of them.
>
> Is there really a use case where you're only interested in specialization
> for certain primitives, but not for others? I guess so, but it seems weird
> to me.
>

On Wed, Jul 8, 2009 at 10:06 PM, Matt Fowles <matt.fowles@gmail.com> wrote:

Nils~

I could easily see wanting to specialize for long and double, but not
int, float, byte, or char

Why?

On Thu, 2009-07-09 at 07:12 -0500, Nils Kilden-Pedersen wrote:
> On Wed, Jul 8, 2009 at 10:06 PM, Matt Fowles
> wrote:
> Nils~
>
> I could easily see wanting to specialize for long and double,
> but not
> int, float, byte, or char
>
> Why?

Because specialization is not free as you need to create classes for
each primitive you want to specialize for.

Best,
Ismael

On Jul 9, 2009, at 2:12 PM, Nils Kilden-Pedersen wrote:

> On Wed, Jul 8, 2009 at 10:06 PM, Matt Fowles
> wrote:
> Nils~
>
> I could easily see wanting to specialize for long and double, but not
> int, float, byte, or char
>
> Why?

Nils,

There are people who are not worried about code size, and they can
just use '@specialized' with no type arguments. The truth is we don't
really know how much this cost is (on the mini benchmarks I tried,
startup time can take a hit of up to 10%, but this is preliminary). So
I would instead ask 'Why not?'

iulian

--
Iulian Dragos
--
http://lamp.epfl.ch/~dragos

On Thu, Jul 9, 2009 at 8:13 AM, Iulian Dragos <iulian.dragos@epfl.ch> wrote:

On Jul 9, 2009, at 2:12 PM, Nils Kilden-Pedersen wrote:

On Wed, Jul 8, 2009 at 10:06 PM, Matt Fowles <matt.fowles@gmail.com> wrote:
Nils~

I could easily see wanting to specialize for long and double, but not
int, float, byte, or char

Why?

Nils,

There are people who are not worried about code size, and they can just use '@specialized' with no type arguments. The truth is we don't really know how much this cost is (on the mini benchmarks I tried, startup time can take a hit of up to 10%, but this is preliminary). So I would instead ask 'Why not?'

Because it doesn't seem like a good case for complicating the compiler. I cannot think of a use case where you'd be interested in performance and less garbage (using @specialized), but only for some primitives. I would think that you either wouldn't use those primitives anyway, or if you do, you'd be interested in the same optimizations for all of them.