I want to add some fuel to the discussion about my favorite multiple recievers, so I've added a small issue to the KEEP: https://github.com/Kotlin/KEEP/issues/209. The issue is built upon the old idea of file-level receivers in KEEP-176. In my opinion, the proposed solution in future could cure a split between KEEP-87 and KEEP-176 followers, fixing a rising concern for scripting framework as well. @raulraja, your comments are welcome.

You forgot one of my favourite proposals, companion vals, where i somehow extended the proposal and did a prototypal implementation of something very similar to what you search for. https://github.com/hannespernpeintner/kotlin/tree/keep-106/compiler/testData/codegen/box/companionval take a look at the CompanionValAtTopLevel.kt file. What is missing to fulfill your need is sth like an "external companion val foo:Foo" thing that may be enabled for Scripts only or so.

Hi @altavir, I very much like your proposal and would fit the use case for type classes. I have developed as part of Arrow Meta a lower level feature called Type Proofs as a compiler plugin that can express type classes, union types, tuples, kinds, refinements and implicit conversions using just extension functions to declare relationships between two types. It does exactly as your proposal does but does not use imports because the proofs are global and coherent in resolution. I will be happy to show you over hang outs if you are interested in this lower level feature that can express more things. We are using it to prototype KEEPs in 2020 for Unions, Refined types and derivation based on structure

There is still a significant difference from what is (or at least was) at KEEP-87, namely this globality. It my proposal, the recievers are specifically local and are bound at use-site, not in declaration site. Meaning you can actually use a stateful object, not only a type-class. I hope that we will be able to find a solution, which suits everyone. Also, I need to mention, that my primary target is of course multipl recievers. File-level receivers are just a nice addition.

yes, I’m also in favor of multiple receivers

Yeah, this is the point where the split lies.

if that is enabled with imports its fine too but then it becomes file scoped implicits not type classes

Yes, we already had a discussion in russian chat. And I agree that it is not exactly type-class. It is bound to the scope, not to a type.

No, this is actually object usage which is quite similar to KEEP-87. I am talking about explicit scope:

with(scope){
  callFunction()  // works
}

I mean if

MyObject

is a class or a global function that provides a value for

MyInterface

the compiler needs to inject it somewhere in the case of enabling syntax by imports

MyObject is just a singleton instance of MyInterface

if you allow generics then you have to somehow express it in the import to disambiguate colliding instances

If it is not an object, you provide only an interface and instantiate an object in the call site.

Generics are hard subject and require a thorough study since type parameter will exist in the whole file. It could break something

cool, is there an example somewhere of that encoding related to Kinds?

Kmath separates operations from data so operations could be added to existing types by specifying the scope. Type binding is explicit, but in some cases it gives the same result as hkt: you can write mathematical expressions without knowing in advance what type will you use. Not in all cases of course. And from Scala/Haskell point of view it is not "true" hkt because of explicit bindings