- About Scala
- In the Enterprise
- Scala Community
- Language Research
- In the Press
- The Scala Team
- Scala's Prehistory
- Contact Us
- Learning Scala
- Tour of Scala
- Scala API
- Setup & Getting Started
- Programming Guides
- Other Guides
- Code Examples
- Scala Developers
Re: Implicit class + inline class SID (Scala Improvement Document)
Mon, 2011-08-22, 14:55
On Aug 22, 2011, at 3:48 PM, Lukas Rytz wrote:
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.
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 [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"?
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!
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.