public kotlin demo

yay, i already solved the pairless problem:

fun findPairless(a : IntArray) : Int {
// Write your solution here
val lonely = HashSet
for (i in a) {
if (lonely.contains(i)) {
lonely.remove(i)
} else {
lonely.add(i)
}
}
val it = lonely.iterator()
if (it != null) {
return it.next()
}
return -1;
}

had to do the null check because everything that a java objects returns
is considered dangerous because it might return null.
all that would have been a single line in scala :)

def findPairless(t: Seq[Int]) = {
t.filterNot(e => t.count(_ == e) % 2 == 0).distinct
}

there are no kotlin collections yet, afaik...

Am 10.01.2012 21:25, schrieb HamsterofDeath:
> in case you didn't know, today is the public preview of kotlin :)
>
> http://kotlin-demo.jetbrains.com/
>
> main differences i spotted:
> + zero overhead null safety instead of options.
> + access to variables inside strings: "hello ${somevar}"
> + automatic casts inside "if (x instanceof Foo)"
> + extension functions
> + generics still available at runtime
> + apparently, it compiles as fast as java
>
> but:
> + no things like implicits, abstract types or destructuring.
>
>
> the first one should be stolen and added to scala. for the second one, i
> heard there is a compiler plugin. the automatic cast can be done via
> enrichment, the fourth also.
>
>
>

I noticed they have a JavaScript back end (in pre alpha stage),
that will be a killer feature if they can have it at their 1.0 release.


2012/1/10 HamsterofDeath <h-star@gmx.de>

in case you didn't know, today is the public preview of kotlin :)

http://kotlin-demo.jetbrains.com/

main differences i spotted:
+ zero overhead null safety instead of options.
+ access to variables inside strings: "hello ${somevar}"
+ automatic casts inside "if (x instanceof Foo)"
+ extension functions
+ generics still available at runtime
+ apparently, it compiles as fast as java

but:
+ no things like implicits, abstract types or destructuring.


the first one should be stolen and added to scala. for the second one, i
heard there is a compiler plugin. the automatic cast can be done via
enrichment, the fourth also.

i like that they seem to have removed the 'new' keyword, don't know why scala kept it, it is really ugly and superfluous (if it were at least Class.new instead of new Class)

On 10 Jan 2012, at 20:25, HamsterofDeath wrote:

> in case you didn't know, today is the public preview of kotlin :)
>
> http://kotlin-demo.jetbrains.com/
>
> main differences i spotted:
> + zero overhead null safety instead of options.
> + access to variables inside strings: "hello ${somevar}"
> + automatic casts inside "if (x instanceof Foo)"
> + extension functions
> + generics still available at runtime
> + apparently, it compiles as fast as java
>
> but:
> + no things like implicits, abstract types or destructuring.
>
>
> the first one should be stolen and added to scala. for the second one, i
> heard there is a compiler plugin. the automatic cast can be done via
> enrichment, the fourth also.
>
>

I have looked at, but I'm not impressed, especially not with their "reified" types:

  class Cell<T>(bla: T)
  fun foo(bla: Cell<Int>) = "Int"
  fun foo(bla: Cell<Long>) = "Long"
  foo(Cell(1))

Crashes the compiler:

Exception in Kotlin compiler: a bug was reported to developers.
Exception in thread "main" java.lang.ClassFormatError: Duplicate method name&signature in class file Greeter

And this doesn't work too:

trait Bar<T>
class Foo : Bar<Long>, Bar<Int> 

Or does "reified types" mean "we put some lipstick on instanceOf tests"?

Bye,

Simon

Exception in Kotlin compiler: a bug was reported to developers.
Exception in thread "main" java.lang.NoSuchMethodError: jet.TypeInfo.isSubtypeOf(Ljet/TypeInfo;)Z

Exception in Kotlin compiler: a bug was reported to developers.
java.lang.IllegalStateException: java.lang.RuntimeException: Error generating method Greeter.greet in org.jetbrains.jet.codegen.CodegenContext$ClassContext@31cafbc6

If I would get an € for every compiler crash I would probably rich by now.

On Tue, Jan 10, 2012 at 7:43 PM, Simon Ochsenreither <simon.ochsenreither@googlemail.com> wrote:

Or does "reified types" mean "we put some lipstick on instanceOf tests"?

Apparently. But it's an interesting solution to solving signature clashes.

But it's an interesting solution to solving signature clashes.

Which they don't seem to use.

The way the JVM works and the way reified generics would change method lookup, assignment compatibility and inheritance rules are greatly at odds with each other.
I was interested how they would solve those problems, but it seems they didn't even try (yet).

Am 11.01.2012 02:43, schrieb Simon Ochsenreither:

I have looked at, but I'm not impressed, especially not with their "reified" types:

  class Cell<T>(bla: T)
  fun foo(bla: Cell<Int>) = "Int"
  fun foo(bla: Cell<Long>) = "Long"
  foo(Cell(1))

Crashes the compiler:

Exception in Kotlin compiler: a bug was reported to developers.
Exception in thread "main" java.lang.ClassFormatError: Duplicate method name&signature in class file Greeter

And this doesn't work too:

trait Bar<T>
class Foo : Bar<Long>, Bar<Int> 

Or does "reified types" mean "we put some lipstick on instanceOf tests"?

Bye,

Simon

afaik they attached some metainfo to instances which is available at runtime, so both of your functions still have the same signature

Exactly. They promised "reified generics", but they delivered some thinly disguised, prettified instanceOf test.

What a shame. I was already excited to see how they have solved the millions of problems around reified generics vs. overloading/overriding/inheritance/assignment-compatibility on the JVM.

On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
wrote:
> Exactly. They promised "reified generics", but they delivered some thinly
> disguised, prettified instanceOf test.
>
> What a shame. I was already excited to see how they have solved the millions
> of problems around reified generics vs.
> overloading/overriding/inheritance/assignment-compatibility on the JVM.

This is an expectation I truly don't understand. I can't conceive of a
way to reify generics without adding a whole layer between JVM and the
generated code -- such as creating classes on demand. So, when people
say they are going to have "reified generics", I always assume erasure
+ automatic manifests.

I remember a recent question on Stack Overflow that used Kotlin and
Ceylon as proof that reification was possible -- before either one was
available. So, Ceylon was released without reification, and Kotlin has
automatic manifests.

+ access to variables inside strings: "hello ${somevar}"

I believe that is being added to scala. 

W dniu 11.01.2012 13:16, Daniel Sobral pisze:
> On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> wrote:
>> Exactly. They promised "reified generics", but they delivered some thinly
>> disguised, prettified instanceOf test.
>>
>> What a shame. I was already excited to see how they have solved the millions
>> of problems around reified generics vs.
>> overloading/overriding/inheritance/assignment-compatibility on the JVM.
>
> This is an expectation I truly don't understand. I can't conceive of a
> way to reify generics without adding a whole layer between JVM and the
> generated code -- such as creating classes on demand. So, when people
> say they are going to have "reified generics", I always assume erasure
> + automatic manifests.
>
> I remember a recent question on Stack Overflow that used Kotlin and
> Ceylon as proof that reification was possible -- before either one was
> available. So, Ceylon was released without reification, and Kotlin has
> automatic manifests.
>

Anyway, instead of bashing imperfect solutions in the other languages,
maybe let's learn something and improve Manifests in Scala slightly?
I mean, in Scala, I can't even check x.isInstanceOf[List[Int]] reliably,
even if I do have all the runtime type info for x thanks to Manifest. A
prettified instanceOf test would be still nice addition, IMHO.

Regards,
Piotr

What's wrong with x match {case l: List[Int] => ? }In which case I agree that it should be able to test the type parameter. I think that's actually being worked on, via the virtual pattern matcher.

2012/1/12 Piotr Kołaczkowski <pkolaczk@elka.pw.edu.pl>

W dniu 11.01.2012 13:16, Daniel Sobral pisze:

On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
<simon.ochsenreither@googlemail.com>  wrote:

Exactly. They promised "reified generics", but they delivered some thinly
disguised, prettified instanceOf test.

What a shame. I was already excited to see how they have solved the millions
of problems around reified generics vs.
overloading/overriding/inheritance/assignment-compatibility on the JVM.

This is an expectation I truly don't understand. I can't conceive of a
way to reify generics without adding a whole layer between JVM and the
generated code -- such as creating classes on demand. So, when people
say they are going to have "reified generics", I always assume erasure
+ automatic manifests.

I remember a recent question on Stack Overflow that used Kotlin and
Ceylon as proof that reification was possible -- before either one was
available. So, Ceylon was released without reification, and Kotlin has
automatic manifests.

Anyway, instead of bashing imperfect solutions in the other languages, maybe let's learn something and improve Manifests in Scala slightly?
I mean, in Scala, I can't even check x.isInstanceOf[List[Int]] reliably, even if I do have all the runtime type info for x thanks to Manifest. A prettified instanceOf test would be still nice addition, IMHO.

Regards,
Piotr

2012/1/12 Piotr Kołaczkowski <pkolaczk@elka.pw.edu.pl>

W dniu 11.01.2012 13:16, Daniel Sobral pisze:

On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
<simon.ochsenreither@googlemail.com>  wrote:

Exactly. They promised "reified generics", but they delivered some thinly
disguised, prettified instanceOf test.

What a shame. I was already excited to see how they have solved the millions
of problems around reified generics vs.
overloading/overriding/inheritance/assignment-compatibility on the JVM.

This is an expectation I truly don't understand. I can't conceive of a
way to reify generics without adding a whole layer between JVM and the
generated code -- such as creating classes on demand. So, when people
say they are going to have "reified generics", I always assume erasure
+ automatic manifests.

I remember a recent question on Stack Overflow that used Kotlin and
Ceylon as proof that reification was possible -- before either one was
available. So, Ceylon was released without reification, and Kotlin has
automatic manifests.

Anyway, instead of bashing imperfect solutions in the other languages, maybe let's learn something and improve Manifests in Scala slightly?
I mean, in Scala, I can't even check x.isInstanceOf[List[Int]] reliably, even if I do have all the runtime type info for x thanks to Manifest. A prettified instanceOf test would be still nice addition, IMHO.

That means that you need to create and store 1 manifest per node in the List. Effectively adding a ton of memory usage.
 

Regards,
Piotr

--
Viktor Klang

Akka Tech LeadTypesafe - The software stack for applications that scale

Twitter: @viktorklang

W dniu 12.01.2012 10:51, Naftoli Gugenheim pisze:
> What's wrong with x match {case l: List[Int] => ? }

That it doesn't work now. :D

> In which case I agree that it should be able to test the type parameter.

Yes, this is exactly what I wanted to say.

> I think that's actually being worked on, via the virtual pattern matcher.

Cool! :)

W dniu 12.01.2012 10:52, √iktor Ҡlang pisze:
>
>
> 2012/1/12 Piotr Kołaczkowski
> >
>
> W dniu 11.01.2012 13:16, Daniel Sobral pisze:
>
> On Wed, Jan 11, 2012 at 05:07, Simon Ochsenreither
> >
> wrote:
>
> Exactly. They promised "reified generics", but they
> delivered some thinly
> disguised, prettified instanceOf test.
>
> What a shame. I was already excited to see how they have
> solved the millions
> of problems around reified generics vs.
> overloading/overriding/__inheritance/assignment-__compatibility
> on the JVM.
>
>
> This is an expectation I truly don't understand. I can't
> conceive of a
> way to reify generics without adding a whole layer between JVM
> and the
> generated code -- such as creating classes on demand. So, when
> people
> say they are going to have "reified generics", I always assume
> erasure
> + automatic manifests.
>
> I remember a recent question on Stack Overflow that used Kotlin and
> Ceylon as proof that reification was possible -- before either
> one was
> available. So, Ceylon was released without reification, and
> Kotlin has
> automatic manifests.
>
>
> Anyway, instead of bashing imperfect solutions in the other
> languages, maybe let's learn something and improve Manifests in
> Scala slightly?
> I mean, in Scala, I can't even check x.isInstanceOf[List[Int]]
> reliably, even if I do have all the runtime type info for x thanks
> to Manifest. A prettified instanceOf test would be still nice
> addition, IMHO.
>
>
> That means that you need to create and store 1 manifest per node in the
> List. Effectively adding a ton of memory usage.
>

1. It is one *pointer* per node more, I can't see why you imply all the
nodes should allocate different Manifest objects.

2. I don't know how lists are implemented internally, but keeping the
Manifest in some kind of a wrapper object, instead of the list nodes,
could be probably done. If not, why?

3. Make that optional.

2012/1/12 √iktor Ҡlang <viktor.klang@gmail.com>

That means that you need to create and store 1 manifest per node in the List. Effectively adding a ton of memory usage.

I think this is overstated, at least for the Sun JVM.

On 32 bit machines, each :: object takes 8 bytes plus whatever data it needs to store (aligned to 4-byte boundaries, plus 4 bytes for array length if the object is an array); on 64 bit machines with compressed oops, it's 12 bytes, but that's rounded up to 16 (object size must be on an 8-byte boundary).  Lists have two pointers, which make them 16 bytes on 32 bit machines, or 20 on 64 bit (rounded up to 24).

If you add an extra pointer in a 32 bit machine, it takes it from 16 bytes to 20, an increase or 25%.  Is this a "ton"?  Not really, I don't think.

If you add an extra pointer in a 64 bit machine, which most people use, it takes it from 20 to 24, which it was rounded to anyway, for no increase at all!  Is this a "ton"?  Certainly not!

Compared to using an effectively-packed data structure like an array, adding manifests is _not_ going to break your memory budget.  If memory is in short supply, you should be staying away from lists anyway.  Use arrays (or ropes based on arrays).

  --Rex

What about Android?