Pre-SIP: Implicit Classes

Perhaps worth adding another explicit restriction in the optimization section about having no side-effects in the implicit class constructor?

alex


On Fri, Mar 27, 2009 at 4:05 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

Here's the first shot at a pre-SIP that provides a little syntax sugar for the Pimp My Library pattern, and allows the compiler to optimize away the object creation that sometimes accompanies it.

http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml

Feedback appreciated,

--j

On Sat, Mar 28, 2009 at 02:05, Jorge Ortiz wrote:
> Here's the first shot at a pre-SIP that provides a little syntax sugar for
> the Pimp My Library pattern, and allows the compiler to optimize away the
> object creation that sometimes accompanies it.
>
> http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml
>
> Feedback appreciated,

Compiler optimization of new instance creation is useless. JVM should
do dirty job and translate

===
new RichInt(x) min y
===

to what you'd like to see

===
if (x < y) x else y
===

it is simple inlining.

S.

Having side effects in your implicits is already a bad idea. However, lacking an effects system, there's no way for the compiler to know whether there are side effects or not. That said, I think the compiler can make meaningful optimizations while preserving the semantics of the program (including side effects). If this turns out not to be the case, then I wouldn't mind removing the guarantee of preserved semantics for side effects (similar to how side effects in pattern matching statements are not guaranteed to do anything rational).

--j
On Mar 27, 2009, at 4:36 PM, Alex Boisvert <boisvert@intalio.com> wrote:

Perhaps worth adding another explicit restriction in the optimization section about having no side-effects in the implicit class constructor?

alex


On Fri, Mar 27, 2009 at 4:05 PM, Jorge Ortiz < (jorge [dot] ortiz [at] gmail [dot] com> wrote:

Here's the first shot at a pre-SIP that provides a little syntax sugar for the Pimp My Library pattern, and allows the compiler to optimize away the object creation that sometimes accompanies it.

http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml

Feedback appreciated,

--j

You have no idea how much I wish this were true. In practice, the JVM
does not optimize this. I believe JDK6u14 adds some escape analysis
and scalar replacement, but performance is still worse than the static
method call (see Ismael Juma's blog for details). In any case, this is
specific to one JVM implementation and not general to others.

If this kind of JVM optimization were efficient and common, then yes,
optimizations performed by the Scala compiler would be useless.
Regardless, I think the syntax for a
common (and currently verbose) language pattern would still be useful.

--j

On Mar 27, 2009, at 4:48 PM, Stepan Koltsov
wrote:

> On Sat, Mar 28, 2009 at 02:05, Jorge Ortiz
> wrote:
>> Here's the first shot at a pre-SIP that provides a little syntax
>> sugar for
>> the Pimp My Library pattern, and allows the compiler to optimize
>> away the
>> object creation that sometimes accompanies it.
>>
>> http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml
>>
>> Feedback appreciated,
>
> Compiler optimization of new instance creation is useless. JVM should
> do dirty job and translate
>
> ===
> new RichInt(x) min y
> ===
>
> to what you'd like to see
>
> ===
> if (x < y) x else y
> ===
>
> it is simple inlining.
>
> S.

Essentially, you're trying to convert something that looks like a wrapper class into a bunch of static methods which take a class as their first argument? (Like C# extension methods).  I agree, it would be great if the compiler could optimize these.  If you provide the annotation as a "fail if you cannot optimize the way I desire", I think the proposal is pretty good.


My only argument would revolve around the import semantics.  While I agree that you really should be importing ClassName._ if you understand the implementation, it seems to fly in the face of intuition from the rest of Scala.   Currently if I have an object with implicit defs, I need to make those *defs* visible in my scope, hence import ObjectName._.   This is similar to how I make any regular-old def in scope.   Using that same paradigm, why wouldn't importing the implicit class into scope also make it available as an implicit conversion?   hence:  import ClassName instead of import ClassName._.  That way it's the same as importing any regular old class, this one just happens to also be implicit (similar to defs).  BTW I'm only making the argument, I actually wouldn't mind either semantic, but the ability to import *not* as implicit would be nice, and I don't have any alternative proposal for that.

I really really like this spec, and hope to see it make its way into Scala! I think you've done a fantastic job.

-Josh

On Fri, Mar 27, 2009 at 9:08 PM, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

Having side effects in your implicits is already a bad idea. However, lacking an effects system, there's no way for the compiler to know whether there are side effects or not. That said, I think the compiler can make meaningful optimizations while preserving the semantics of the program (including side effects). If this turns out not to be the case, then I wouldn't mind removing the guarantee of preserved semantics for side effects (similar to how side effects in pattern matching statements are not guaranteed to do anything rational).

--j
On Mar 27, 2009, at 4:36 PM, Alex Boisvert <boisvert@intalio.com> wrote:

Perhaps worth adding another explicit restriction in the optimization section about having no side-effects in the implicit class constructor?

alex


On Fri, Mar 27, 2009 at 4:05 PM, Jorge Ortiz <jorge.ortiz@gmail.comjorge.ortiz@gmail.com> wrote:

Here's the first shot at a pre-SIP that provides a little syntax sugar for the Pimp My Library pattern, and allows the compiler to optimize away the object creation that sometimes accompanies it.

http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml

Feedback appreciated,

--j

On Friday March 27 2009, Jorge Ortiz wrote:
> ... I believe JDK6u14 adds some escape analysis
> and scalar replacement, but performance is still worse than the
> static method call (see Ismael Juma's blog for details). ...

Are you referring to this?

> --j

Randall Schulz

Yes, thanks. I'm on my phone so I can't paste the link.

--j

On Mar 27, 2009, at 6:32 PM, Randall R Schulz wrote:

> On Friday March 27 2009, Jorge Ortiz wrote:
>> ... I believe JDK6u14 adds some escape analysis
>> and scalar replacement, but performance is still worse than the
>> static method call (see Ismael Juma's blog for details). ...
>
> Are you referring to this?
>
> >
>
>
>> --j
>
>
> Randall Schulz

Josh Suereth wrote:
> hence: import ClassName instead of import ClassName._

+1 import of class members relays on generated implementation. This
process should be completely hidden by compiler.

On Fri, Mar 27, 2009 at 6:20 PM, Josh Suereth wrote:
> Essentially, you're trying to convert something that looks like a wrapper
> class into a bunch of static methods which take a class as their first
> argument? (Like C# extension methods).  I agree, it would be great if the
> compiler could optimize these.  If you provide the annotation as a "fail if
> you cannot optimize the way I desire", I think the proposal is pretty good.

That's the idea in a nut shell.

>
>
> My only argument would revolve around the import semantics.  While I agree
> that you really should be importing ClassName._ if you understand the
> implementation, it seems to fly in the face of intuition from the rest of
> Scala.   Currently if I have an object with implicit defs, I need to make
> those *defs* visible in my scope, hence import ObjectName._.   This is
> similar to how I make any regular-old def in scope.   Using that same
> paradigm, why wouldn't importing the implicit class into scope also make it
> available as an implicit conversion?   hence:  import ClassName instead of
> import ClassName._.  That way it's the same as importing any regular old
> class, this one just happens to also be implicit (similar to defs).  BTW I'm
> only making the argument, I actually wouldn't mind either semantic, but the
> ability to import *not* as implicit would be nice, and I don't have any
> alternative proposal for that.

In this situation, you couldn't realistically have "top level"
implicit classes, because otherwise implicits could be in scope
without being explicitly imported. Consider:

// foo/Bar.scala

package foo

implicit class Bar(x: Int) { /* ... */ ;

// foo/Baz.scala
package foo;

class Baz {
// is the Int=>Bar conversion in scope here? There's been no import.
// If it's not, how do I import it under the alternative import semantics?
}

I don't like either of the solutions of the above, so I'd rather the
current proposal. One alternative would be to name the generated
method something more meaningful than apply (we thought of
"conversion"), but that didn't seem like a great idea.

On Sat, Mar 28, 2009 at 04:14, Jorge Ortiz wrote:
> You have no idea how much I wish this were true. In practice, the JVM does
> not optimize this. I believe JDK6u14 adds some escape analysis and scalar
> replacement, but performance is still worse than the static method call (see
> Ismael Juma's blog for details). In any case, this is specific to one JVM
> implementation and not general to others.

If JVM does not optimize, then JVM should be patched, not the scala
compiler. Scala compiler is already complex enough and has another
problems to be fixed.

> If this kind of JVM optimization were efficient and common, then yes,
> optimizations performed by the Scala compiler would be useless. Regardless,
> I think the syntax for a
> common (and currently verbose) language pattern would still be useful.

Yes, syntax would be useful. However, probably better syntax is

class RichInt implicit (n: Int) { ... }

because the conversion method should implicit (and class may have many
constructors), not the whole class.

S.

> On Mar 27, 2009, at 4:48 PM, Stepan Koltsov
> wrote:
>
>> On Sat, Mar 28, 2009 at 02:05, Jorge Ortiz wrote:
>>>
>>> Here's the first shot at a pre-SIP that provides a little syntax sugar
>>> for
>>> the Pimp My Library pattern, and allows the compiler to optimize away the
>>> object creation that sometimes accompanies it.
>>>
>>> http://jorgeortiz85.github.com/ImplicitClassSIP.xhtml
>>>
>>> Feedback appreciated,
>>
>> Compiler optimization of new instance creation is useless. JVM should
>> do dirty job and translate
>>
>> ===
>> new RichInt(x) min y
>> ===
>>
>> to what you'd like to see
>>
>> ===
>> if (x < y) x else y
>> ===
>>
>> it is simple inlining.
>>
>> S.
>

On Sat, Mar 28, 2009 at 7:06 AM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sat, Mar 28, 2009 at 04:14, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:

> If this kind of JVM optimization were efficient and common, then yes,
> optimizations performed by the Scala compiler would be useless. Regardless,
> I think the syntax for a
> common (and currently verbose) language pattern would still be useful.

Yes, syntax would be useful. However, probably better syntax is

class RichInt implicit (n: Int) { ... }

because the conversion method should implicit (and class may have many
constructors), not the whole class.

S.

I think given this syntax, then the import RichInt._ makes sense.   I understand that implementing the way I proposed earlier would be technically harder, especially with how scala resolves names + packages.  However, I still think that if the syntax is "implicit Class", it means the class itself is implicit, and the import Class._ isn't as intuitive. 

Besdies, imagine this world:

object Conversions {
    implicit class RichInt(n : Int) {
         def someNewMethod = n to infinity!
    }
}

You still have the flexibility, you have the implicit class niceness AND you can import the class appropriately.   It's like any other language feature that needs to be used wisely.  Once again, I'm not really pushing hard for this syntax, as I understand the proposal as stands is fairly easy to implement.  I'd just rather see A) the constructor be implicit + have to imported for the conversion to work or B) things stay as they are and if the class is available in the current scope, the implicit is also available.  That just feels more natural to my scala mindset.

-Josh

On Sat, Mar 28, 2009 at 6:06 AM, Stepan Koltsov <stepan.koltsov@gmail.com> wrote:

On Sat, Mar 28, 2009 at 04:14, Jorge Ortiz <jorge.ortiz@gmail.com> wrote:
> You have no idea how much I wish this were true. In practice, the JVM does
> not optimize this. I believe JDK6u14 adds some escape analysis and scalar
> replacement, but performance is still worse than the static method call (see
> Ismael Juma's blog for details). In any case, this is specific to one JVM
> implementation and not general to others.

If JVM does not optimize, then JVM should be patched, not the scala
compiler. Scala compiler is already complex enough and has another
problems to be fixed.

I'm reasonably certain that the JVM at this point is much more complicated than most compilers, including Scala's, since it is itself a compiler and a lot more.
With that said, Scala has some real world performance problems, and just crossing our fingers and hoping that the VM guys will fix them is not good enough. Particularly if one does not run a Sun VM.
Plenty of people seem to want to run Scala on mobile phones too and the kind of unnecessary slop (decorator objects instead of static method calls) isn't helping.

On Sat, Mar 28, 2009 at 16:36, Nils Kilden-Pedersen wrote:
>> On Sat, Mar 28, 2009 at 04:14, Jorge Ortiz wrote:
>> > You have no idea how much I wish this were true. In practice, the JVM
>> > does
>> > not optimize this. I believe JDK6u14 adds some escape analysis and
>> > scalar
>> > replacement, but performance is still worse than the static method call
>> > (see
>> > Ismael Juma's blog for details). In any case, this is specific to one
>> > JVM
>> > implementation and not general to others.
>>
>> If JVM does not optimize, then JVM should be patched, not the scala
>> compiler. Scala compiler is already complex enough and has another
>> problems to be fixed.
>
> I'm reasonably certain that the JVM at this point is much more complicated
> than most compilers, including Scala's,

I'm not sure. JVM is a compiler too. It is more complicated then Scala
compiler, partly because JVM does much more optimizations then Scala
compier does. If Scala compiler get more optimizations then one day
hacking Scala will be as difficult as hacking JVM.

> since it is itself a compiler and a
> lot more.

But Scala compiler has lots of problems, more important then such
microoptimizations. Compiler performance is one of the most important
problem.

> With that said, Scala has some real world performance problems, and just
> crossing our fingers and hoping that the VM guys will fix them is not good
> enough. Particularly if one does not run a Sun VM.
> Plenty of people seem to want to run Scala on mobile phones

Both of them? I doubt there is a real demand for Scala on phones.

> too and the kind
> of unnecessary slop (decorator objects instead of static method calls) isn't
> helping.

S.