6 Replies Last post: Jul 2, 2012 10:30 AM by Andrey Breslav  
Eric Springer Newbie 4 posts since
Jul 1, 2012
Currently Being Moderated

Jul 1, 2012 5:56 AM

On Generics

Hi!

 

I spent the last couple of days playing with Kotlin, and thought I'd give my feedback. In general, I'm extremely impressed with the language and its direction. I think it's got real potential and I'm very tempted to hacking on an llvm backend. However, the generic system worries me a little.

 

Variance and type reification is super nice, so I'm really glad you've identified that. But I'm a bit concerned that you might be falling into the same traps as scala and its type reification (ala Manifests). I feel the Tuple{1-23} and {X}Array is evidence of this.

 

And sooner or later, people will need things like scala's HList's (An arbitrarily nested Tuple2 with a whole bunch of sugar) e.g. https://github.com/milessabin/shapeless

 

Most of which could be avoided by providing by starting with a better designed "generic" system. I think D is an extremely good example of it done pretty well, and C++11 to a much lesser extent.

 

I personally think a type system really needs to support variadic generics (e.g. Tuple<vararg T> ) along with the ability to provided specialized definitions e.g. "Array<Short>" that "code-generates" a specialized version.

 

Now I know I'm asking too much, but the other thing I find very missing in scala is the ability to put values in the type system. Often there's times I want something like: FixedSizeArray<32, Int> or even a NodeDepth<3> (as you'll see in the Scala sources, they often resort to using a preproccessor to code-generate something like FixedSizeArray32<Int> and NodeDepth3.

 


Thanks!
Keep up the awesome work

Cedric Beust Novice 122 posts since
Mar 1, 2012
Currently Being Moderated
Jul 1, 2012 10:09 AM in response to: Eric Springer
Re: On Generics

Hi Eric,

 

I'd be curious to see you expand on this and give a few examples where you think these advanced features would be useful, in particular the Shapeless type (awesome technical work but still a bit of a curiosity to me) and dependent types (still struggling to find some practical uses to these, more details here).

Andrey Breslav Apprentice 872 posts since
Jun 11, 2007
Currently Being Moderated
Jul 1, 2012 8:03 PM in response to: Eric Springer
Re: On Generics

Hi Eric,

 

Thanks for your interest in Kotlin.

 

What I gathered from your post is that you request a template-based approach to generic classes:

  • ability to specialize implementation for particular arguments,
  • ability to metaprogram with (hopefully, compile-time-constant) numbers in types.

 

Please, don't call C++ "a nice type system". To our standards of understandability, C++ has a very non-nice type system: too permissive, too cryptic errors.

Maybe "concepts" somewhat fix that one day, but they didn't quite work out so far... And tey seem to be a rather complex machinery.

 

We investigated template-like design options and went for what we have now (no reification at all, arrays specialized for primitives) for a bunch of reasons mainly coming from the constraints imposed by the Java ecosystem:

  • Dynamic class loading (crucial for very any applications) makes any kind of implicit (C++-style) templating very hard
    • if we are to generate specialized classes, in what class loader should they sit?
    • and if not in the system one, how will different libraries talk to each other?
    • if we are for runtime generation, this problem does not go away and we have performance penalties on top...
    • This proposal attempts to work around this issue: KT-744, the story there is mostly about "if you want to build a code generator into your language, you'd better isolate it somehow".
  • Reification (even something Scala-like) messes up the Java interfaces of Kotlin code, which is problematic in a heterogenous project.

 

This does not mean that there's no way we can do (some of) what you request. The question is: how much of it is both really necessary and possible to implement without compromising other aspects of the language.

It seems that rather few people actually want all that power. But these people are very bright and passionate, and I like them, so I'll do my best to please them

 

I would be very interested to discuss what you propose further. My experience is that on early stages of such discussions it can be much easier to talk (e.g. over skype), than to exchange forum messages/emails.

If you would like to talk it over, you can reach me at "andrey dot breslav at jetbrains dot com" to arrange a call.

 

P.S. On the llvm back-end: there are some preliminary discussions about this going on in our team. If you would like to participate, we'll find a way to arrange it.

Andrey Breslav Apprentice 872 posts since
Jun 11, 2007
Currently Being Moderated
Jul 2, 2012 10:30 AM in response to: Eric Springer
Re: On Generics

I don't know enough about this problem, but perhaps it can be alleviated by only allowing specializations of a class from within the same "module" it was defined in or something?

This means that I can't use templates for public library classes, like collections.

 

I think you'd still have to resort to runtime class generation, but at least you should at least know what classloader has to do it and with some pre-create hints it might not be too bad at all. (e.g. Tuple$1 to Tuple$10 might be pre-generated by the class loader -- but anything more would be created on the fly).

Most of the time the right class loader is the system class loader that we have no control over.

More Like This

  • Retrieving data ...