Re: Implicit class + inline class SID (Scala Improvement Document)

On Aug 22, 2011, at 3:48 PM, Lukas Rytz wrote:

On Mon, Aug 22, 2011 at 15:34, Josh Suereth <joshua.suereth@gmail.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.

If you want to check for purity this article articles seems to give a nice approach to purity analysis. Haven't implemented it yet though so don't know how well it works: http://dspace.mit.edu/handle/1721.1/30470

On Mon, Aug 22, 2011 at 9:21 AM, Lukas Rytz <lukas.rytz@epfl.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.suereth@gmail.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