Over the course of the last few years, I have prepared a package of far-reaching language design pro...

# language-proposals

[Alexander Kuklev]

Over the course of the last few years, I have prepared a package of far-reaching language design proposals significantly improving expressiveness and reducing boilerplate. The list includes in particular
• Painless type providers,
• First-class logic programming,
• Effortless dependency injection
As opposed to small incremental improvements, such ideas will only go into development if a significant number of users are eager to have them.

Please take a look at https://akuklev.github.io/kotlin/, discuss and share if you would like to see some of these features in Kotlin.

[joseph_ivie]

Type providers looks very very hard to implement, thought it would certainly be cool.

[Hunter]

Some thoughts:
1. The query "type" (not sure what to call it) in the second proposal would be very interesting, and I can see definite applications for some unique quantum computing framework support in kotlin, which would be very cool.
2. The dependency injection proposal, as it stands, seems hard to follow and too niche. I don't like the idea of seemingly magic and nested default parameters, and it doesn't solve the issue of wanting to share a singleton object across an application. What if, instead, there was something like a lateinit object, similar to a lateinit var. It's an object with a constructor that must be called before use and can only be called once, otherwise a special error is thrown. This allows users to manually specify their dependencies on startup, or provide a default.

[Youssef Shoaib [MOD]]

I think you can do a lot of the type provider stuff with FirFunctionCallRefinementExtension, which DataFrame uses. The string formatting example can very easily be done by generating a local class for this specific string formatter, refining the return type of format to thus be that class, and then it will continue to work just fine with named arguments.

[Youssef Shoaib [MOD]]

The logic programming stuff is already (almost) possible in Kotlin! You just have to be able to clone continuations. There's already prior work on how to implement logic programming using (multishot multiprompt) delimited continuations. I have implemented these approaches in Kotlin using Kontinuity, my library for (multishot multiprompt) delimited continuations and effect handlers. Your logic programming examples would translate very elegantly using it, I believe. I might try to translate some of them as a useful example.

I think effects are a perfect fit for Kotlin, and so they should inform some of these proposals more.

[Youssef Shoaib [MOD]]

Startup and dependency injection feels too magical, and should thus be left to frameworks or annotation processors. I don't see why you'd particularly want to use @Main instead of just fun main(args: Array<String>) = with(OurApp(args)) { ... }.
Some of the dependency initializtaion stuff can be done rather well with context parameters, and maybe something like wither to reduce nesting.

[Youssef Shoaib [MOD]]

Typeclasses is a really interesting idea! however, I think it goes against the grain of Kotlin to add them in the way proposed. Instead, it should play nicely with contexts. I can already write a Monoid really easily:

interface Monoid<M> {
  operator fun M.plus(other: M): M
  val empty: M
}

and use it as a context (with apt bridge functions). The missing part right now is some way to get the context automatically. In other words, given instances from Scala are the way. I think Scala also has nice syntax where you can say T: Monoid, and it adds a Monoid<T> context parameter as a result.