Implicit class + inline class SID (Scala Improvement Document)

Hi Josh,

I think it's awesome, but it needs more cowbell!

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

Hi Josh,

I think it's awesome, but it needs more cowbell!

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

I thought about embedding the "tale of captain jack sparrow" just for you.

2011/8/22 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Hi Josh,

I think it's awesome, but it needs more cowbell!

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

I thought about embedding the "tale of captain jack sparrow" just for you.

2011/8/22 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Hi Josh,

I think it's awesome, but it needs more cowbell!

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

Is there a discussion somewhere that explains why currently pimps and typeclasses can't be inlined? Is it purely that this isn't functionality that's been implemented yet, or are there genuine roadblocks that are addressed in your proposal?
Thanks,
Matthew  

On 22 August 2011 14:09, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

I thought about embedding the "tale of captain jack sparrow" just for you.

2011/8/22 √iktor Ҡlang <viktor [dot] klang [at] gmail [dot] com>

Hi Josh,

I think it's awesome, but it needs more cowbell!

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster [at] gmail [dot] com gchat: turingatemyhamster [at] gmail [dot] commsn: matthew_pocock [at] yahoo [dot] co [dot] uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

This is really great stuff!

Now to my constructive feedback. ;-)

I think it would be nice to be able to define implicit classes at the
top level. The generated implicit method could then be put in a
generated companion object. But the question would be how to import
the implicit conversion then. Importing using the name of the implicit
class would not work, which is a shame. Am I right that this is one of
the reasons why the proposal does not allow implicit classes at the
top level?

But why does it say in the "Specification" paragraph: "The language
specification (SLS 7.1) would be modified to allow the use of the
implicit modifier for classes, even at the top-level."? Emphasis on
"even at the top-level".

Also, I like the idea of desugaring implicit class method invocations
to static method calls. It would be nice if this was also done when
not using the optimizer, as I'm always quite hesitant to use it, given
its track record of not speeding things up, slowing down compilation
and introducing bugs (at least it seems to me this way).

Regards,
Rüdiger

2011/8/22 Josh Suereth :
> Cross-posting to scala-language + scala-internals because I wasn't sure
> where else to push this.
>
> You asked for it, and it's ready for public viewing!   Here is a modified
> proposal for implicit classes that includes the ability to inline classes.
> The ulitmate goal of this proposal is for better 'implicit' performance
> within Scala.   Specifically for the extension method + typeclass/typetrait
> patterns embedded in Scala implicits.
> Please take a look and offer constructive feedback!
> https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc...
>
> Note:  This proposal does not include any syntax sugar fixes for defining
> typeclasses.  I have an alternative, much more controversial, SID that
> outlines an annotaiton-based approach to generating typeclass boilerlate.  I
> can send it to those who are interested, because it's designed to be
> acheived via annotations + a compiler plugin currently.
> - Josh
>

This is really great stuff!

Now to my constructive feedback. ;-)

I think it would be nice to be able to define implicit classes at the
top level. The generated implicit method could then be put in a
generated companion object. But the question would be how to import
the implicit conversion then. Importing using the name of the implicit
class would not work, which is a shame. Am I right that this is one of
the reasons why the proposal does not allow implicit classes at the
top level?

But why does it say in the "Specification" paragraph: "The language
specification (SLS 7.1) would be modified to allow the use of the
implicit modifier for classes, even at the top-level."? Emphasis on
"even at the top-level".

Also, I like the idea of desugaring implicit class method invocations
to static method calls. It would be nice if this was also done when
not using the optimizer, as I'm always quite hesitant to use it, given
its track record of not speeding things up, slowing down compilation
and introducing bugs (at least it seems to me this way).

Regards,
Rüdiger

2011/8/22 Josh Suereth :
> Cross-posting to scala-language + scala-internals because I wasn't sure
> where else to push this.
>
> You asked for it, and it's ready for public viewing!   Here is a modified
> proposal for implicit classes that includes the ability to inline classes.
> The ulitmate goal of this proposal is for better 'implicit' performance
> within Scala.   Specifically for the extension method + typeclass/typetrait
> patterns embedded in Scala implicits.
> Please take a look and offer constructive feedback!
> https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc...
>
> Note:  This proposal does not include any syntax sugar fixes for defining
> typeclasses.  I have an alternative, much more controversial, SID that
> outlines an annotaiton-based approach to generating typeclass boilerlate.  I
> can send it to those who are interested, because it's designed to be
> acheived via annotations + a compiler plugin currently.
> - Josh
>

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

In the interest of keeping it simple to start, I was only going to allow classes with no parents to be inlined.  Kind of like a POD-type from C++.  Other classes would generate a compiler warning.   I would love to support the Rich* classes though.  I wonder if we could compromise with some kind of compromise...
for example RichInt could be marked @inline if all parents were also @inline, and then we can place restrictions on constructors to compile....  WDYT?



On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

On Mon, Aug 22, 2011 at 9:22 AM, Ruediger Keller <ruediger [dot] keller [at] rk42 [dot] de> wrote:

This is really great stuff!

Now to my constructive feedback. ;-)

I think it would be nice to be able to define implicit classes at the
top level. The generated implicit method could then be put in a
generated companion object. But the question would be how to import
the implicit conversion then. Importing using the name of the implicit
class would not work, which is a shame. Am I right that this is one of
the reasons why the proposal does not allow implicit classes at the
top level?

I think you nailed it on the head.  This is a no-go because it means 'implicit class ' operates differently from every other 'implicit foo' in the language.   However you *could* put the implicit class on a package object, which is akin to top-level.

But why does it say in the "Specification" paragraph: "The language
specification (SLS 7.1) would be modified to allow the use of the
implicit modifier for classes, even at the top-level."? Emphasis on
"even at the top-level".

Copy-Paste Error!!! Good catch, thanks! 

Also, I like the idea of desugaring implicit class method invocations
to static method calls. It would be nice if this was also done when
not using the optimizer, as I'm always quite hesitant to use it, given
its track record of not speeding things up, slowing down compilation
and introducing bugs (at least it seems to me this way).

That's a great question.  I want @inline classes to work regardless of -optimise or not, but the aggression of it may change... 

Regards,
Rüdiger


2011/8/22 Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>:
> Cross-posting to scala-language + scala-internals because I wasn't sure
> where else to push this.
>
> You asked for it, and it's ready for public viewing!   Here is a modified
> proposal for implicit classes that includes the ability to inline classes.
> The ulitmate goal of this proposal is for better 'implicit' performance
> within Scala.   Specifically for the extension method + typeclass/typetrait
> patterns embedded in Scala implicits.
> Please take a look and offer constructive feedback!
> https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US
>
> Note:  This proposal does not include any syntax sugar fixes for defining
> typeclasses.  I have an alternative, much more controversial, SID that
> outlines an annotaiton-based approach to generating typeclass boilerlate.  I
> can send it to those who are interested, because it's designed to be
> acheived via annotations + a compiler plugin currently.
> - Josh
>

On 22 August 2011 14:21, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

 you end up needing an effect system..

It does seem that most fun things we'd like to do with improving the scala compiler come back to this.
Matthew 

Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

--
Dr Matthew PocockVisitor, School of Computing Science, Newcastle Universitymailto: turingatemyhamster [at] gmail [dot] com gchat: turingatemyhamster [at] gmail [dot] commsn: matthew_pocock [at] yahoo [dot] co [dot] uk irc.freenode.net: drdozertel: (0191) 2566550mob: +447535664143

In the interest of keeping it simple to start, I was only going to allow classes with no parents to be inlined.  Kind of like a POD-type from C++.  Other classes would generate a compiler warning.   I would love to support the Rich* classes though.  I wonder if we could compromise with some kind of compromise...
for example RichInt could be marked @inline if all parents were also @inline, and then we can place restrictions on constructors to compile....  WDYT?



On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

On Mon, Aug 22, 2011 at 9:22 AM, Ruediger Keller <ruediger [dot] keller [at] rk42 [dot] de> wrote:

This is really great stuff!

Now to my constructive feedback. ;-)

I think it would be nice to be able to define implicit classes at the
top level. The generated implicit method could then be put in a
generated companion object. But the question would be how to import
the implicit conversion then. Importing using the name of the implicit
class would not work, which is a shame. Am I right that this is one of
the reasons why the proposal does not allow implicit classes at the
top level?

I think you nailed it on the head.  This is a no-go because it means 'implicit class ' operates differently from every other 'implicit foo' in the language.   However you *could* put the implicit class on a package object, which is akin to top-level.

But why does it say in the "Specification" paragraph: "The language
specification (SLS 7.1) would be modified to allow the use of the
implicit modifier for classes, even at the top-level."? Emphasis on
"even at the top-level".

Copy-Paste Error!!! Good catch, thanks! 

Also, I like the idea of desugaring implicit class method invocations
to static method calls. It would be nice if this was also done when
not using the optimizer, as I'm always quite hesitant to use it, given
its track record of not speeding things up, slowing down compilation
and introducing bugs (at least it seems to me this way).

That's a great question.  I want @inline classes to work regardless of -optimise or not, but the aggression of it may change... 

Regards,
Rüdiger


2011/8/22 Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>:
> Cross-posting to scala-language + scala-internals because I wasn't sure
> where else to push this.
>
> You asked for it, and it's ready for public viewing!   Here is a modified
> proposal for implicit classes that includes the ability to inline classes.
> The ulitmate goal of this proposal is for better 'implicit' performance
> within Scala.   Specifically for the extension method + typeclass/typetrait
> patterns embedded in Scala implicits.
> Please take a look and offer constructive feedback!
> https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US
>
> Note:  This proposal does not include any syntax sugar fixes for defining
> typeclasses.  I have an alternative, much more controversial, SID that
> outlines an annotaiton-based approach to generating typeclass boilerlate.  I
> can send it to those who are interested, because it's designed to be
> acheived via annotations + a compiler plugin currently.
> - Josh
>

On Mon, Aug 22, 2011 at 15:34, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

In the interest of keeping it simple to start, I was only going to allow classes with no parents to be inlined.  Kind of like a POD-type from C++.  Other classes would generate a compiler warning.   I would love to support the Rich* classes though.  I wonder if we could compromise with some kind of compromise...
for example RichInt could be marked @inline if all parents were also @inline, and then we can place restrictions on constructors to compile....  WDYT?

Sounds reasonable to me. An easy solution to check purity would be to allow only methods in @inline classes, no fields.

On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

On Mon, Aug 22, 2011 at 15:34, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

In the interest of keeping it simple to start, I was only going to allow classes with no parents to be inlined.  Kind of like a POD-type from C++.  Other classes would generate a compiler warning.   I would love to support the Rich* classes though.  I wonder if we could compromise with some kind of compromise...
for example RichInt could be marked @inline if all parents were also @inline, and then we can place restrictions on constructors to compile....  WDYT?

Sounds reasonable to me. An easy solution to check purity would be to allow only methods in @inline classes, no fields.

On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas [dot] rytz [at] epfl [dot] ch> wrote:

The transformation from "new Foo(2) plus 2" to "Foo.methods$.plus(1, 2)" preservessemantics only if the constructor of "Foo" does not have side-effects. Since "Foo"
might have superclass(es), as in 

  class RichInt(n: Int) extends Ordered[Int]
this is not trivial so to check; you'd need know that the super constructor call is side-effect-free, and you end up needing an effect system.. What's the plan? Just trust the user that inlining is fine when he writes "@inline class"?
Lukas

On Mon, Aug 22, 2011 at 14:29, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

By the way, i started implementing @inline classes a while back (~ 2009) but both me and Iulian were busy with other things at the time so it never got finished. I'm attaching the old implementation below, maybe you will find pieces of it useful.- Tiark
Begin forwarded message:

From: Tiark Rompf <tr [at] nachtlicht-media [dot] de>
Date: July 17, 2009 4:18:49 PM GMT+02:00
To: Dragos Iulian <iulian [dot] dragos [at] epfl [dot] ch>
Subject: Escape Analysis/Scalar Replacement patch

Hi Iulian,

here's the patch and a simple test case. I cleaned up Inliners.scala a little bit again, and inserted a test against Flags.ACCESSOR instead of bumping up the retry threshold globally (as you suggested).

You can find the benchmark code I was aiming to improve here: http://lamp.epfl.ch/~rompf/vector2/

The relevant one there is BenchAVectorHeadTailEsc, which should run significantly faster than BenchAVectorHeadTail (see timingsEscape.txt).

Two concerns

1. It seems to me that the inlining semantics moves a lot of runtime responsibility into the semantics of the language. To me this is a smell, the language should be optimized for expressibility and not concern it self with the runtime semantics too much.

I do think it can, and should, make sure that the language semantics is such that certain runtime optimization _can_ be performed.

So IMHO an alternative approach would be to just specify that @inline means that an object instantiation _can_ be inlined, but not enforce in the language semantics that it _will_ be inlined. Then add a compiler option to scalac that enforce the inlining in the compiler. Not as a language semantic but as a compiler feature.

Now that is  just my opinion. What triggers it is that the SID specifies not only inlining of object construction but also of method calls. While the former is not very reliable on current VMs the latter should be solid by now.


2. The SID explicitly targets performance of a particular pattern aimed at syntactic convenience. I agree with the general approach of removing the runtime semantics implied by the pattern, they are, so to speak, accidental complexity. I also think it is a good thing that the implicit class syntax remove some boilerplate associated with expressing the pattern.

However, as the goal of the changes in this SID seems to be to remove class semantics from the boiler plate required to gain a purely syntactic benefit, maybe a better approach is to add a syntactic sugar not implying any class semantics in the first place? Besides, adding implicit semantics to classes might introduce conflicts with other ways of addressing the boilerplate.

So, if the motivation is to gain infix notation for type classes maybe explicit support for infix operations could be added?

trait TypeClass[T] {
  def operation(t1:T,t2:T):T
  infix @ = operation
}

or

trait TypeClass[T] {
  def (t1:T) @ (t1:T): T
}

I'm just addressing the use of implicit classes for infix methods of type classes here. The use of implicit classes when one really wants class semantics is a nice addition. I just fear that it might interfere with more targeted boilerplate reductions for the type class pattern.

BR,
John

On Mon, Aug 22, 2011 at 2:29 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

Another thing: Is it true that, given an implicit class, it is not
possible to define a companion object for that class? I think that's the
case because for an 'implicit class Foo' there will be a generated
method called 'Foo'; adding an 'object Foo' would result in a name clash.

(Sorry if that's obvious, but I couldn't find anything about it.)

Another thing: Is it true that, given an implicit class, it is not
possible to define a companion object for that class? I think that's the
case because for an 'implicit class Foo' there will be a generated
method called 'Foo'; adding an 'object Foo' would result in a name clash.

(Sorry if that's obvious, but I couldn't find anything about it.)

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

On Mon, Aug 22, 2011 at 8:29 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

This was discussed.  Originally I had them separate, but this has been nixed.  @inline will most likely place a lot of restrictions on the class itself that are unecessary for general classes.

On Mon, Aug 22, 2011 at 4:36 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

On Mon, Aug 22, 2011 at 8:29 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

This was discussed.  Originally I had them separate, but this has been nixed.  @inline will most likely place a lot of restrictions on the class itself that are unecessary for general classes.

On Mon, Aug 22, 2011 at 4:36 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

On Mon, Aug 22, 2011 at 8:29 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Cross-posting to scala-language + scala-internals because I wasn't sure where else to push this.

You asked for it, and it's ready for public viewing!   Here is a modified proposal for implicit classes that includes the ability to inline classes.   The ulitmate goal of this proposal is for better 'implicit' performance within Scala.   Specifically for the extension method + typeclass/typetrait patterns embedded in Scala implicits.
Please take a look and offer constructive feedback!
https://docs.google.com/document/d/1k-aGAGmbrDB-2pJ3uDPpHVKno6p-XbnkVHDc07zPrzQ/edit?hl=en_US

Note:  This proposal does not include any syntax sugar fixes for defining typeclasses.  I have an alternative, much more controversial, SID that outlines an annotaiton-based approach to generating typeclass boilerlate.  I can send it to those who are interested, because it's designed to be acheived via annotations + a compiler plugin currently.
- Josh

responses inline

On Mon, Aug 22, 2011 at 3:58 PM, John Nilsson <john [at] milsson [dot] nu> wrote:

Two concerns

1. It seems to me that the inlining semantics moves a lot of runtime responsibility into the semantics of the language. To me this is a smell, the language should be optimized for expressibility and not concern it self with the runtime semantics too much.

I do think it can, and should, make sure that the language semantics is such that certain runtime optimization _can_ be performed.

So IMHO an alternative approach would be to just specify that @inline means that an object instantiation _can_ be inlined, but not enforce in the language semantics that it _will_ be inlined. Then add a compiler option to scalac that enforce the inlining in the compiler. Not as a language semantic but as a compiler feature.

Now that is  just my opinion. What triggers it is that the SID specifies not only inlining of object construction but also of method calls. While the former is not very reliable on current VMs the latter should be solid by now.

I think we need both at this point in time to be able to inline the most common pattern:
@inline implicit final def impOps(x: Foo) = new FooOps(x)*and* @inline class FooOps(x: Foo) {   def +(y: Foo) = ...}
(x: Foo) + y  
desugars to:
impOps(x).+(y)
Which would *not* have any inlining.    You need to have both in the compiler so that the interactions between class inlining and method inlining happen.  Otherwise you're severely restricting the later.  You're right that if the JVM optimised this, it would not be needed.
As for making it optional... I'd prefer to have this optimisation on by default, but I could see adding a flag to prevent it's occurrence.  As for the annotation, I see it more akin to the "tailrec" optimisation.   It ensures that something can, and is, optimised so there is no confusion as to what's happening.  However, unlike those others, I think the search space for inline classes may be too high to justify running on un-annotated classes.
Look forward to your thoughts on these responses :)
- Josh

 

2. The SID explicitly targets performance of a particular pattern aimed at syntactic convenience. I agree with the general approach of removing the runtime semantics implied by the pattern, they are, so to speak, accidental complexity. I also think it is a good thing that the implicit class syntax remove some boilerplate associated with expressing the pattern.

However, as the goal of the changes in this SID seems to be to remove class semantics from the boiler plate required to gain a purely syntactic benefit, maybe a better approach is to add a syntactic sugar not implying any class semantics in the first place? Besides, adding implicit semantics to classes might introduce conflicts with other ways of addressing the boilerplate.

So, if the motivation is to gain infix notation for type classes maybe explicit support for infix operations could be added?

trait TypeClass[T] {
  def operation(t1:T,t2:T):T
  infix @ = operation
}

or

trait TypeClass[T] {
  def (t1:T) @ (t1:T): T
}

I'm just addressing the use of implicit classes for infix methods of type classes here. The use of implicit classes when one really wants class semantics is a nice addition. I just fear that it might interfere with more targeted boilerplate reductions for the type class pattern.

There's actually a separate SID for type classes.   This SiD will just bring their performance up-to-snuff if they use "Ops" classes.   The implicit class portion of this proposal is targeted at "extension method" patterns in Scala, which typeclass Ops are but a small fraction of.  the Rich* classes in Scala are other examples.
My specific proposal for typeclasses is not quite ready for prime time viewing.  It's a very controversial topic, as I'm sure the syntax you suggested, if it were in a proposal, would be as well.   However, I appreciate the ideas, and I'll incorporate them in the second proposal.   I'd like to focus on the inlining proposal first, because this remove the runtime punishments for using type-class + extension method patterns.

The aim was that, just as with case classes, you can create the companion object and override generated functionality yourself.  I'll add this explicitly to the SID.
- Josh

On Mon, Aug 22, 2011 at 4:00 PM, Lars Hupel <hupel [at] in [dot] tum [dot] de> wrote:

Another thing: Is it true that, given an implicit class, it is not
possible to define a companion object for that class? I think that's the
case because for an 'implicit class Foo' there will be a generated
method called 'Foo'; adding an 'object Foo' would result in a name clash.

(Sorry if that's obvious, but I couldn't find anything about it.)

responses inline

On Mon, Aug 22, 2011 at 3:58 PM, John Nilsson <john [at] milsson [dot] nu> wrote:

Two concerns

1. It seems to me that the inlining semantics moves a lot of runtime responsibility into the semantics of the language. To me this is a smell, the language should be optimized for expressibility and not concern it self with the runtime semantics too much.

I do think it can, and should, make sure that the language semantics is such that certain runtime optimization _can_ be performed.

So IMHO an alternative approach would be to just specify that @inline means that an object instantiation _can_ be inlined, but not enforce in the language semantics that it _will_ be inlined. Then add a compiler option to scalac that enforce the inlining in the compiler. Not as a language semantic but as a compiler feature.

Now that is  just my opinion. What triggers it is that the SID specifies not only inlining of object construction but also of method calls. While the former is not very reliable on current VMs the latter should be solid by now.

I think we need both at this point in time to be able to inline the most common pattern:
@inline implicit final def impOps(x: Foo) = new FooOps(x)*and* @inline class FooOps(x: Foo) {   def +(y: Foo) = ...}
(x: Foo) + y  
desugars to:
impOps(x).+(y)
Which would *not* have any inlining.    You need to have both in the compiler so that the interactions between class inlining and method inlining happen.  Otherwise you're severely restricting the later.  You're right that if the JVM optimised this, it would not be needed.
As for making it optional... I'd prefer to have this optimisation on by default, but I could see adding a flag to prevent it's occurrence.  As for the annotation, I see it more akin to the "tailrec" optimisation.   It ensures that something can, and is, optimised so there is no confusion as to what's happening.  However, unlike those others, I think the search space for inline classes may be too high to justify running on un-annotated classes.
Look forward to your thoughts on these responses :)
- Josh

 

2. The SID explicitly targets performance of a particular pattern aimed at syntactic convenience. I agree with the general approach of removing the runtime semantics implied by the pattern, they are, so to speak, accidental complexity. I also think it is a good thing that the implicit class syntax remove some boilerplate associated with expressing the pattern.

However, as the goal of the changes in this SID seems to be to remove class semantics from the boiler plate required to gain a purely syntactic benefit, maybe a better approach is to add a syntactic sugar not implying any class semantics in the first place? Besides, adding implicit semantics to classes might introduce conflicts with other ways of addressing the boilerplate.

So, if the motivation is to gain infix notation for type classes maybe explicit support for infix operations could be added?

trait TypeClass[T] {
  def operation(t1:T,t2:T):T
  infix @ = operation
}

or

trait TypeClass[T] {
  def (t1:T) @ (t1:T): T
}

I'm just addressing the use of implicit classes for infix methods of type classes here. The use of implicit classes when one really wants class semantics is a nice addition. I just fear that it might interfere with more targeted boilerplate reductions for the type class pattern.

There's actually a separate SID for type classes.   This SiD will just bring their performance up-to-snuff if they use "Ops" classes.   The implicit class portion of this proposal is targeted at "extension method" patterns in Scala, which typeclass Ops are but a small fraction of.  the Rich* classes in Scala are other examples.
My specific proposal for typeclasses is not quite ready for prime time viewing.  It's a very controversial topic, as I'm sure the syntax you suggested, if it were in a proposal, would be as well.   However, I appreciate the ideas, and I'll incorporate them in the second proposal.   I'd like to focus on the inlining proposal first, because this remove the runtime punishments for using type-class + extension method patterns.

On Mon, Aug 22, 2011 at 10:59 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

I think we need both at this point in time to be able to inline the most common pattern:

I was actually reacting at "a third pass of the inliner will attempt to remove any method calls after class inlining has been acheived" which, granted, was a little bit knee-jerk. Given the first two inlining passes I guess nothing significantly different is introduced by a third pass. It just strikes me as something belonging to the runtime. I'm a bit weary of removing information about the original program before it VM has chance to look at it.

 

@inline implicit final def impOps(x: Foo) = new FooOps(x) *and* @inline class FooOps(x: Foo) {   def +(y: Foo) = ...}
(x: Foo) + y  
desugars to:
impOps(x).+(y)

Yes, I can see how the first pass is required to enable the second pass. I'm thinking that all three passes can be avoided given a different language semantic though.
 

As for making it optional... I'd prefer to have this optimisation on by default, but I could see adding a flag to prevent it's occurrence.  As for the annotation, I see it more akin to the "tailrec" optimisation.   It ensures that something can, and is, optimised so there is no confusion as to what's happening.  However, unlike those others, I think the search space for inline classes may be too high to justify running on un-annotated classes.

I'm not against having it on by default. I'm just thinking that it should be defined as a feature of the typsafe implementation of a scala compiler and not feature of the language as such.
 

Now back to the @inline vs implicit class semantic:

If, instead of generating an implicit def, the implicit lookup rules are changed to also look for implicit constructors (now theres an interesting distinction, is it a constructor for an implicit class, or is it an implicit constructor for a class? The latter allows for more than one implicit definition for the same class...) there is no longer a need for the factory method, and thus no need for the first inlining pass.


So at least the inlining is limited to just construction. I still maintain, though, that the implied semantics
of "@inline implicit class" is to nullify the effects of "new". Which feel awkward, why do I need to use one language construct to remove the effects of another when I can just not use the one I want to avoid?

I think Pimp my Library as well as type classes share the common problem of wanting convenient syntax without paying the object tax. Its not only the possible overhead of heap allocation (a concern that really shouldn't have anything to do with the language, being entirely a runtime implementation issue), it's also questions like do my wrapper have a separate identity? What does "this" mean when defining an extension method? Can I place a lock on the wrapper? Will another method call to the "same" object see the lock?

All those questions are, in my opinion, valid reasons for wanting to remove the effects of new. But in my mind we are searching for a language construct that gives us what we want, instead of one that removes what we don't want. And if I understand what is left after we remove new it's just some infix method calls.


BR,
John

I don't understand your reply--*what* has been nixed?

I specifically proposed @inline(SILENT), which means that if the implicit class can't be inlined, the compiler won't complain (but won't inline it either).

Unless you mean that if you @inline something, it only complains at _use_ sites and not if the class itself is inherently incompatible.  In that case, if you really need to distinguish the two, I suggest adding another option to the annotation to make the compiler try to incorporate inlining information into the class, but not to complain if it can't (and then use that on the implicit classes).

One of the main lessons I've learned from Java is that the common use cases should be easy to type or when reading code you public static final get lost in the mostly-meaningless clutter throws IDontCareAboutThisException.

  --Rex

On Mon, Aug 22, 2011 at 4:48 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

This was discussed.  Originally I had them separate, but this has been nixed.  @inline will most likely place a lot of restrictions on the class itself that are unecessary for general classes.

On Mon, Aug 22, 2011 at 4:36 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

I think one important point to make is that @inline annotation makes *no* change to the language itself, just to the compiler.   If the behavior of a class changes when @inline is in place, than this is a failed SID.  Whereas adding infix notation for methods is a massive language change.  If you look at the spec changes, all of them are relating to "implicit class".   In fact, I debated splitting this proposal into 2 chunks, inline classes and implicit classes so we can debate merits separately.  However, combined they make a more coherent picture.  (Also note, the original proposal was 4 chunks, 2 of which are not in discussion, yet).
I see what you're saying with the third pass to remove methods.   I can remove that from the SID as it's most likely not necessary, and we do want the JVM to do what it does best.
I understand what you're saying about taking things we don't want away.  Isn't that what the inline class proposal is doing?  Removing the performance hit for simple wrapper classes?  This goes beyond 'extension method' and 'type trait' idioms.
As for the implicit class syntax, I personally am a fan, but when push comes to shove it's the inline class stuff I want in Scala ASAP.   I can wait for sugar, but performance is powerful.  I do think the proposed syntax makes sense, but your idea of implicit *constructors* is really powerful.  I'm hoping Martin is reading this to discuss.  However, if it's an implicit constructor, I would guess the annotation (implicit in this case) would have to be where constructor annotations exist, which feels a bit odd.   Let me toy with that idea (and farm it around) a bit, as i think you may be onto something big.
- Josh


On Mon, Aug 22, 2011 at 6:35 PM, John Nilsson <john [at] milsson [dot] nu> wrote:

On Mon, Aug 22, 2011 at 10:59 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

I think we need both at this point in time to be able to inline the most common pattern:

I was actually reacting at "a third pass of the inliner will attempt to remove any method calls after class inlining has been acheived" which, granted, was a little bit knee-jerk. Given the first two inlining passes I guess nothing significantly different is introduced by a third pass. It just strikes me as something belonging to the runtime. I'm a bit weary of removing information about the original program before it VM has chance to look at it.

 

@inline implicit final def impOps(x: Foo) = new FooOps(x) *and* @inline class FooOps(x: Foo) {   def +(y: Foo) = ...}
(x: Foo) + y  
desugars to:
impOps(x).+(y)

Yes, I can see how the first pass is required to enable the second pass. I'm thinking that all three passes can be avoided given a different language semantic though.
 

As for making it optional... I'd prefer to have this optimisation on by default, but I could see adding a flag to prevent it's occurrence.  As for the annotation, I see it more akin to the "tailrec" optimisation.   It ensures that something can, and is, optimised so there is no confusion as to what's happening.  However, unlike those others, I think the search space for inline classes may be too high to justify running on un-annotated classes.

I'm not against having it on by default. I'm just thinking that it should be defined as a feature of the typsafe implementation of a scala compiler and not feature of the language as such.
 

Now back to the @inline vs implicit class semantic:

If, instead of generating an implicit def, the implicit lookup rules are changed to also look for implicit constructors (now theres an interesting distinction, is it a constructor for an implicit class, or is it an implicit constructor for a class? The latter allows for more than one implicit definition for the same class...) there is no longer a need for the factory method, and thus no need for the first inlining pass.


So at least the inlining is limited to just construction. I still maintain, though, that the implied semantics
of "@inline implicit class" is to nullify the effects of "new". Which feel awkward, why do I need to use one language construct to remove the effects of another when I can just not use the one I want to avoid?

I think Pimp my Library as well as type classes share the common problem of wanting convenient syntax without paying the object tax. Its not only the possible overhead of heap allocation (a concern that really shouldn't have anything to do with the language, being entirely a runtime implementation issue), it's also questions like do my wrapper have a separate identity? What does "this" mean when defining an extension method? Can I place a lock on the wrapper? Will another method call to the "same" object see the lock?

All those questions are, in my opinion, valid reasons for wanting to remove the effects of new. But in my mind we are searching for a language construct that gives us what we want, instead of one that removes what we don't want. And if I understand what is left after we remove new it's just some infix method calls.


BR,
John

I think one important point to make is that @inline annotation makes *no* change to the language itself, just to the compiler.   If the behavior of a class changes when @inline is in place, than this is a failed SID.  Whereas adding infix notation for methods is a massive language change.  If you look at the spec changes, all of them are relating to "implicit class".   In fact, I debated splitting this proposal into 2 chunks, inline classes and implicit classes so we can debate merits separately.  However, combined they make a more coherent picture.  (Also note, the original proposal was 4 chunks, 2 of which are not in discussion, yet).
I see what you're saying with the third pass to remove methods.   I can remove that from the SID as it's most likely not necessary, and we do want the JVM to do what it does best.
I understand what you're saying about taking things we don't want away.  Isn't that what the inline class proposal is doing?  Removing the performance hit for simple wrapper classes?  This goes beyond 'extension method' and 'type trait' idioms.
As for the implicit class syntax, I personally am a fan, but when push comes to shove it's the inline class stuff I want in Scala ASAP.   I can wait for sugar, but performance is powerful.  I do think the proposed syntax makes sense, but your idea of implicit *constructors* is really powerful.  I'm hoping Martin is reading this to discuss.  However, if it's an implicit constructor, I would guess the annotation (implicit in this case) would have to be where constructor annotations exist, which feels a bit odd.   Let me toy with that idea (and farm it around) a bit, as i think you may be onto something big.
- Josh


On Mon, Aug 22, 2011 at 6:35 PM, John Nilsson <john [at] milsson [dot] nu> wrote:

On Mon, Aug 22, 2011 at 10:59 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

I think we need both at this point in time to be able to inline the most common pattern:

I was actually reacting at "a third pass of the inliner will attempt to remove any method calls after class inlining has been acheived" which, granted, was a little bit knee-jerk. Given the first two inlining passes I guess nothing significantly different is introduced by a third pass. It just strikes me as something belonging to the runtime. I'm a bit weary of removing information about the original program before it VM has chance to look at it.

 

@inline implicit final def impOps(x: Foo) = new FooOps(x) *and* @inline class FooOps(x: Foo) {   def +(y: Foo) = ...}
(x: Foo) + y  
desugars to:
impOps(x).+(y)

Yes, I can see how the first pass is required to enable the second pass. I'm thinking that all three passes can be avoided given a different language semantic though.
 

As for making it optional... I'd prefer to have this optimisation on by default, but I could see adding a flag to prevent it's occurrence.  As for the annotation, I see it more akin to the "tailrec" optimisation.   It ensures that something can, and is, optimised so there is no confusion as to what's happening.  However, unlike those others, I think the search space for inline classes may be too high to justify running on un-annotated classes.

I'm not against having it on by default. I'm just thinking that it should be defined as a feature of the typsafe implementation of a scala compiler and not feature of the language as such.
 

Now back to the @inline vs implicit class semantic:

If, instead of generating an implicit def, the implicit lookup rules are changed to also look for implicit constructors (now theres an interesting distinction, is it a constructor for an implicit class, or is it an implicit constructor for a class? The latter allows for more than one implicit definition for the same class...) there is no longer a need for the factory method, and thus no need for the first inlining pass.


So at least the inlining is limited to just construction. I still maintain, though, that the implied semantics
of "@inline implicit class" is to nullify the effects of "new". Which feel awkward, why do I need to use one language construct to remove the effects of another when I can just not use the one I want to avoid?

I think Pimp my Library as well as type classes share the common problem of wanting convenient syntax without paying the object tax. Its not only the possible overhead of heap allocation (a concern that really shouldn't have anything to do with the language, being entirely a runtime implementation issue), it's also questions like do my wrapper have a separate identity? What does "this" mean when defining an extension method? Can I place a lock on the wrapper? Will another method call to the "same" object see the lock?

All those questions are, in my opinion, valid reasons for wanting to remove the effects of new. But in my mind we are searching for a language construct that gives us what we want, instead of one that removes what we don't want. And if I understand what is left after we remove new it's just some infix method calls.


BR,
John

@inline(SILENT) automatically on implicit classes was discussed and nixed.  I agree that if it's added 99% of the time, then it should be default.  The proposal actually had this originally, but when discussing with Martin, we decided to remove it.  I'm still on the fence here so you could persuade *me*, but then we'd have to persuade *Martin* :)
Note: One option for inline classes is that the compiler can do inline checking for *every* class and only use the annotation to *ensure* that the optimization happens (like @tailrec and @switch).  In that case, there would be no issue with adding @inline or not, and @inline(SILENT) would go away.
- Josh

On Mon, Aug 22, 2011 at 6:47 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

I don't understand your reply--*what* has been nixed?

I specifically proposed @inline(SILENT), which means that if the implicit class can't be inlined, the compiler won't complain (but won't inline it either).

Unless you mean that if you @inline something, it only complains at _use_ sites and not if the class itself is inherently incompatible.  In that case, if you really need to distinguish the two, I suggest adding another option to the annotation to make the compiler try to incorporate inlining information into the class, but not to complain if it can't (and then use that on the implicit classes).

One of the main lessons I've learned from Java is that the common use cases should be easy to type or when reading code you public static final get lost in the mostly-meaningless clutter throws IDontCareAboutThisException.

  --Rex

On Mon, Aug 22, 2011 at 4:48 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

This was discussed.  Originally I had them separate, but this has been nixed.  @inline will most likely place a lot of restrictions on the class itself that are unecessary for general classes.

On Mon, Aug 22, 2011 at 4:36 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

Of the 273 cases of implicit defs in the PML-pattern in code I've written, 143 are simply because Scala does not have inline methods (and thus of course would want some sort of @inline on implicit classes automatically), and the other 130 would all not be harmed if @inline was considered.  (I think it would succeed on ~half.)

So I could argue it approaches 99% for me.

  --Rex

On Mon, Aug 22, 2011 at 6:59 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

@inline(SILENT) automatically on implicit classes was discussed and nixed.  I agree that if it's added 99% of the time, then it should be default.  The proposal actually had this originally, but when discussing with Martin, we decided to remove it.  I'm still on the fence here so you could persuade *me*, but then we'd have to persuade *Martin* :)
Note: One option for inline classes is that the compiler can do inline checking for *every* class and only use the annotation to *ensure* that the optimization happens (like @tailrec and @switch).  In that case, there would be no issue with adding @inline or not, and @inline(SILENT) would go away.
- Josh

On Mon, Aug 22, 2011 at 6:47 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

I don't understand your reply--*what* has been nixed?

I specifically proposed @inline(SILENT), which means that if the implicit class can't be inlined, the compiler won't complain (but won't inline it either).

Unless you mean that if you @inline something, it only complains at _use_ sites and not if the class itself is inherently incompatible.  In that case, if you really need to distinguish the two, I suggest adding another option to the annotation to make the compiler try to incorporate inlining information into the class, but not to complain if it can't (and then use that on the implicit classes).

One of the main lessons I've learned from Java is that the common use cases should be easy to type or when reading code you public static final get lost in the mostly-meaningless clutter throws IDontCareAboutThisException.

  --Rex

On Mon, Aug 22, 2011 at 4:48 PM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

This was discussed.  Originally I had them separate, but this has been nixed.  @inline will most likely place a lot of restrictions on the class itself that are unecessary for general classes.

On Mon, Aug 22, 2011 at 4:36 PM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Is there any advantage to having implicit classes that are not inlined?  If not, maybe implicit classes can be automatically marked @inline(SILENT) to avoid the extra boilerplate?  (I point to case classes for precedent for grouping useful functionality together.)

  --Rex

Hi Josh,
How about overriding the generated implicit definition?
One useful thing which I can do with the current idiom is:
trait Functionality {  implicit def addFunction[T](t: T) = new AddFunction(t)  class AddFunction[T](t: T) {     def function = ...  }}
and
trait Client extends Functionality {  // "deactivate" the implicit  override def addFunction[T](t: T) = super.addFunction(t)
  // "string".function will not compile anymore}

For this to work with implicit classes, I have to rely on the generated name for the implicit definition, don't I? Is it an issue?
Thanks,
Eric.

you could still override it, as the method has *the same* name as the class...
It's still a good point though... how to remove implicits.
Note:  A non-final class in a trait may not get inlined in an expression, depending on where it shows up.  The compiler has to know that the class is closed when it inlines things.   Therefore your method would have to be final to be inlined, as would the class itself.   That's an interesting wrinkle in the implicit class proposal.
let me think about that one, any ideas welcome :)
- Josh

On Mon, Aug 22, 2011 at 7:34 PM, etorreborre <etorreborre [at] gmail [dot] com> wrote:

Hi Josh,
How about overriding the generated implicit definition?
One useful thing which I can do with the current idiom is:
trait Functionality {  implicit def addFunction[T](t: T) = new AddFunction(t)  class AddFunction[T](t: T) {     def function = ...  }}
and
trait Client extends Functionality {  // "deactivate" the implicit  override def addFunction[T](t: T) = super.addFunction(t)
  // "string".function will not compile anymore}

For this to work with implicit classes, I have to rely on the generated name for the implicit definition, don't I? Is it an issue?
Thanks,
Eric.

you could still override it, as the method has *the same* name as the class...
It's still a good point though... how to remove implicits.
Note:  A non-final class in a trait may not get inlined in an expression, depending on where it shows up.  The compiler has to know that the class is closed when it inlines things.   Therefore your method would have to be final to be inlined, as would the class itself.   That's an interesting wrinkle in the implicit class proposal.
let me think about that one, any ideas welcome :)
- Josh

On Mon, Aug 22, 2011 at 7:34 PM, etorreborre <etorreborre [at] gmail [dot] com> wrote:

Hi Josh,
How about overriding the generated implicit definition?
One useful thing which I can do with the current idiom is:
trait Functionality {  implicit def addFunction[T](t: T) = new AddFunction(t)  class AddFunction[T](t: T) {     def function = ...  }}
and
trait Client extends Functionality {  // "deactivate" the implicit  override def addFunction[T](t: T) = super.addFunction(t)
  // "string".function will not compile anymore}

For this to work with implicit classes, I have to rely on the generated name for the implicit definition, don't I? Is it an issue?
Thanks,
Eric.