new language "Kotlin" from jetbrains

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Something akin to newtype/deriving is a better choice than both. There
was a recent related discussion. Leave the wrap/unwrap up to the
compiler ot JVM as Martin says, though this does affect termination
semantics.

On 20/07/11 22:54, Dennis Haupt wrote:
> when everything besides "pimp my lib" is irrelevant, then extension
> functions are the better choice. they are simpler and are
> guaranteed not to add a performance penaltly. when wrapping stuff
> at runtime, you cannot be sure in advance what the vm will optimize
> away and what it won't.
>
> however, implicit conversions are more powerful - wrapping stuff
> temporarily is just one use case that happens to have to same
> effect as extension functions. extension functions can't actually
> wrap/convert an object, so if you want to do that, you'll have to
> do it manually.
>
> -------- Original-Nachricht --------
>> Datum: Wed, 20 Jul 2011 05:28:08 -0700 (PDT) Von: Rob Patro
>> An: scala-debate
>> Betreff: [scala-debate] Re: new
>> language "Kotlin" from jetbrains
>
>> Martin,
>>
>> I was wondering if you could comment a little bit on the
>> performance tradeoff of extension functions vs. implicit
>> conversions. When the Kotlin page claims that Scala wraps values
>> into adapters at runtime
>> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
>>
>>
this seems like a bit of a mischaracterization to me. It's true that
>> implicits require a rich wrapper to be created at runtime, but
>> determination of the wrapper, and the actual "wrapping" seem to
>> be happening at compile-time. There's some debate about this
>> happening on reddit
>> (http://www.reddit.com/r/programming/comments/iub22/
>> project_kotlin_a_new_statically_typed_programming/c26rgu0), and I
>> was hoping you might comment on some of the arguments being made
>> there.
>>
>> Cheers, Rob
>>
>> On Jul 20, 3:02 am, martin odersky
>> wrote:
>>> On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr
>>> wrote:
>>>> On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips
>> wrote:
>>>
>>>>> Maybe I'm the last guy to hear about things (it happens
>>>>> enough) but there's this language here which looks like a
>>>>> more credible effort to
>> be
>>>>> a better/simpler scala than most:
>>>
>>>>> http://confluence.jetbrains.net/display/Kotlin/Welcome
>>>
>>>>> The "What Kotlin has that Scala has not" list does read
>>>>> like a list
>> of
>>>>> things I would not mind having:
>>>
>>>>> http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
>>>
>>>>>
>>>>>
It makes me sad to see another whole implementation's worth of effort
>>>>> being poured into something new -- come on guys, you won't
>>>>> be enough better than scala. I know everyone wants their
>>>>> own baby, but just imagine what we might accomplish if we
>>>>> didn't all keep re-running the same opening mile. The
>>>>> scenery up here on mile two, it's nice, you should come
>>>>> give it a look.
>>>
>>>>> P.S. First mile is long.
>>>
>>>> They've only gone (or planned) a few hundred yards in a
>>>> direction that Scala hasn't already been.
>>>
>>>> The key ones to my eye are
>>>
>>>> (1) Extension functions. Much cleaner syntax and better
>> performance than
>>>> the Pimp My Library pattern using implicits.
>>>
>>> Extension functions are shortsighted because they only make a
>>> class get
>> new
>>> methods but do not let it implement new interfaces. In any
>>> mature
>> framework,
>>> the primary reason for a method to exist is to implement some
>>> interface. Extension functions don't scale up to that usage.
>>>
>>> Cheers
>>>
>>> -- Martin

And how about type level programming, or defining type level constraints ?
I see this a compelling use case for implicit params and conversions.

ML

2011/7/20 Dennis Haupt <h-star [at] gmx [dot] de>

when everything besides "pimp my lib" is irrelevant, then extension functions are the better choice. they are simpler and are guaranteed not to add a performance penaltly. when wrapping stuff at runtime, you cannot be sure in advance what the vm will optimize away and what it won't.

however, implicit conversions are more powerful - wrapping stuff temporarily is just one use case that happens to have to same effect as extension functions. extension functions can't actually wrap/convert an object, so if you want to do that, you'll have to do it manually.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 05:28:08 -0700 (PDT)
> Von: Rob Patro <rob [dot] patro [at] gmail [dot] com>
> An: scala-debate <scala-debate [at] googlegroups [dot] com>
> Betreff: [scala-debate] Re: new language "Kotlin" from jetbrains

> Martin,
>
>   I was wondering if you could comment a little bit on the performance
> tradeoff of extension functions vs. implicit conversions.  When the
> Kotlin page claims that Scala wraps values into adapters at runtime
> (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> this seems like a bit of a mischaracterization to me.  It's true that
> implicits require a rich wrapper to be created at runtime, but
> determination of the wrapper, and the actual "wrapping" seem to be
> happening at compile-time. There's some debate about this happening on
> reddit (http://www.reddit.com/r/programming/comments/iub22/
> project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> hoping you might comment on some of the arguments being made there.
>
> Cheers,
> Rob
>
> On Jul 20, 3:02 am, martin odersky <martin [dot] oder [dot] [dot] [dot] [at] epfl [dot] ch> wrote:
> > On Wed, Jul 20, 2011 at 4:16 AM, Rex Kerr <icho [dot] [dot] [dot] [at] gmail [dot] com> wrote:
> > > On Tue, Jul 19, 2011 at 7:29 PM, Paul Phillips
> <pa [dot] [dot] [dot] [at] improving [dot] org>wrote:
> >
> > >> Maybe I'm the last guy to hear about things (it happens enough) but
> > >> there's this language here which looks like a more credible effort to
> be
> > >> a better/simpler scala than most:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Welcome
> >
> > >> The "What Kotlin has that Scala has not" list does read like a list
> of
> > >> things I would not mind having:
> >
> > >>  http://confluence.jetbrains.net/display/Kotlin/Comparison+to+Scala
> >
> > >> It makes me sad to see another whole implementation's worth of effort
> > >> being poured into something new -- come on guys, you won't be enough
> > >> better than scala.  I know everyone wants their own baby, but just
> > >> imagine what we might accomplish if we didn't all keep re-running the
> > >> same opening mile.  The scenery up here on mile two, it's nice, you
> > >> should come give it a look.
> >
> > >> P.S. First mile is long.
> >
> > > They've only gone (or planned) a few hundred yards in a direction that
> > > Scala hasn't already been.
> >
> > > The key ones to my eye are
> >
> > >   (1) Extension functions.  Much cleaner syntax and better
> performance than
> > > the Pimp My Library pattern using implicits.
> >
> > Extension functions are shortsighted because they only make a class get
> new
> > methods but do not let it implement new interfaces. In any mature
> framework,
> > the primary reason for a method to exist is to implement some interface.
> > Extension functions don't scale up to that usage.
> >
> > Cheers
> >
> >  -- Martin

Here's how Kotlin implements reification: "For now, we attach a field
with a TypeInfo object to every instance of a generic class. I'm not
aware of any other reliable ways to reify the type
information" (http://confluence.jetbrains.net/display/Kotlin/Welcome?
focusedCommentId=40703305&#comment-40703305).

just found:
http://confluence.jetbrains.net/display/Kotlin/Tuples

they have labeled tuples, meaning you can access the attributes by names instead of _1, _2 and so on

this is a feature worth of being copied.
first idea:

val magicTuple:(x,y) = (1,2)

is short for

class aslkdjfsdfh(x:Int,y:Int) extends tuple2(x,y)
val magicTUple = new asd(1,2)

so the caller also benefits from the names.

-------- Original-Nachricht --------
> Datum: Wed, 20 Jul 2011 14:32:12 +0200
> Von: martin odersky
> An: Rob Patro
> CC: scala-debate
> Betreff: Re: [scala-debate] Re: new language "Kotlin" from jetbrains

> On Wed, Jul 20, 2011 at 2:28 PM, Rob Patro wrote:
>
> > Martin,
> >
> > I was wondering if you could comment a little bit on the performance
> > tradeoff of extension functions vs. implicit conversions. When the
> > Kotlin page claims that Scala wraps values into adapters at runtime
> > (http://confluence.jetbrains.net/display/Kotlin/Extension+functions),
> > this seems like a bit of a mischaracterization to me. It's true that
> > implicits require a rich wrapper to be created at runtime, but
> > determination of the wrapper, and the actual "wrapping" seem to be
> > happening at compile-time. There's some debate about this happening on
> > reddit (http://www.reddit.com/r/programming/comments/iub22/
> > project_kotlin_a_new_statically_typed_programming/c26rgu0), and I was
> > hoping you might comment on some of the arguments being made there.
> >
> >
> See my earlier mail in this thread:
>
> It's pretty straightforward to optimize these wrappers away, either in the
> compiler or in the JVM. I have so far resisted making them a special case
> (which we could) because I think that a decent general purpose optimizer
> should be able to eliminate the object creation and call indirection,
> generating in effect the same code as an extension method. Scala
> optimizers
> evolve more slowly than I would like, but it's no reason to give up and
> instead throw more features into the language.
>

So I've been spending a lot of time trying to optimize the Numeric type
class (see https://github.com/azavea/numeric) and I am of two minds on
the issue of whether it's worth doing specific optimization of wrapper
objects created by implicit decorators.

At Scalathon I started working on a compiler plugin to "cut out the
middle man" and translate things like "new Numeric(a).+(b)" directly
into "numeric.plus(a, b)" to avoid the object creation, and performance
problems I noticed in 2.9 (2-3x slow down).

Beyond the plugin (which isn't working yet) I've been going through a
lot of contortions to try to make sure Numeric is running as fast as
possible. So I definitely agree with Rex that it would be nice for
(relatively) low hanging optimization fruit to be picked--otherwise
users are forced to (each independently) determine which constructs are
the fastest and which to avoid.

But on the other hand, in HEAD the performance of my Numeric type class
is *much* better (based on recent tests), and I'm only seeing about a
(roughly) 4% penalty for using the implicit wrappers in the "normal"
case [1]. I'm not sure whether the compiler has started doing specific
optimizations or if it just happens to produce code that Hotspot has an
easier time optimizing. But it does lend some credence to Martin's
position.

That said, at the end of the day I would like things to be fast, and
will probably end up using whatever it takes to get that performance
(e.g. Arrays, while loops, the scala-CL compiler plugin, custom Numeric
type class, etc).

On Wed, Jul 20, 2011 at 4:20 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Wed, Jul 20, 2011 at 9:33 AM, Rex Kerr <ichoran [at] gmail [dot] com> wrote:

Another area of scalability is to manage large quantities of runtime data, e.g. with millions of objects.  GC is a pain in such situations, and there, I'd argue that PML is the one that doesn't scale (not unless escape analysis is perfect), because the cost-per-object gets increasingly expensive as the object churn goes up, while extension functions have fewer limits.

It's pretty straightforward to optimize these wrappers away, either in the compiler or in the JVM. I have so far resisted making them a special case (which we could) because I think that a decent general purpose optimizer should be able to eliminate the object creation and call indirection, generating in effect the same code as an extension method. Scala optimizers evolve more slowly than I would like, but it's no reason to give up and instead throw more features into the language.

I'm all for having _compiler_ optimizations instead of language features.  But assuming that the JVM can handle everything is equivalent, for the medium term, to assuming that Scala is going to run on the Sun JVM where those optimizations exist, and hopefully not on Dalvik or elsewhere where they do not.  Of course, optimizations that no JVM can't do, due to lack of information, should have elevated priority.  But that doesn't mean that the others should be entirely neglected.

Besides, I think extension functions are just a generalization of what the language already has, namely multiple parameter lists.  Suppose you could put the parameter name wherever you please:

    def g(a: A)(b: B) = // ...
    g(a)(b)

    def (a: A)g(b: B) = // ...
    (a) g (b)
    a g b

    def (a: A)(b: B)g = // ...
    (a)(b)g

    def ~(a: A) = // ...
    ~ a

    def (a: A)~ = // ...
    a ~

And if you're going to have multiple parameter lists, why not multiple identifiers?  Compare (assuming that Range doesn't already have a by method):

    // Existing way to make DSL for int ranges
    implicit def x(i: Int) = new { def to(j: Int) = Range.inclusive(i,j) }
    implicit def y(r: Range) = new {
      def by(k: Int) = if (r.isInclusive) Range.inclusive(r.start,r.end,k) else Range(r.start,r.end,k)
    }

    // Suggested way to make DSL for int ranges
    def (i: Int) to (j: Int) by (k: Int) = Range.inclusive(i,j,k)

This really doesn't make the _language_ spec much more complex.  It also doesn't make the expressivity of the language any more complex (except for the variant that would allow more-than-one-initial-parameter).  You can already achieve all of this with the existing features, except that it's very clunky to write, has potential performance problems, and leads to strange allowed syntax:

    1 to 7 by 3 by 2   // Huh? Is this 1,4,7 or 1,6 or 1,3,5,7??

Finally, keep in mind that the JVM-applied optimizations so far only make things _better_, not identical to a method call.  For example, I get ~50% slowdown with x.isNaN compared to java.lang.Double.isNaN, and ~8x slowdown with a max b (for doubles) compared to math.max(a,b).

So I'd argue that extension methods are a special case of a modest increase in flexibility of method parameters, and that if PML is intended to replace extension methods entirely, that a compiler optimization not a JVM optimization is called for (since the best optimizing JVM still can't do it completely or very frequently).

  --Rex

On Sat, Jul 23, 2011 at 6:03 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:

What is the theory upon which Kotlin is based?

The theory of evolution?
 

After looking at Kotlin's extension functions in details I think it is a major blunder comparing to implicits in Scala. They may be easier to handle in IDE (and IDEA's Scala plugin already handles implicits perfectly) - but there's no way I can do away without ability to convert one type to another at least here in GridGain's code. 
Just adding a function to another type (primitive "pimping") is just one specific application of implicits - and it seems that kotlin team wrongly assumed that that's the only one at all...
I'm surprised they'd allow such a significant comparative drawback for their language.
--Nikita Ivanov, CEOGridGain Systemswww.gridgain.com