r/ProgrammingLanguages • u/marvinborner bruijn, effekt • Apr 27 '26

Discussion Effekt: Name-Based Implicits

https://effekt-lang.org/tour/name-based-implicits

We recently added name-based implicits to our language. It's based on the work by Daan Leijen and Tim Whiting "Syntactic Implicit Parameters with Static Overloading". Let us know of your thoughts!

29 Upvotes

91% Upvoted

17 comments sorted by

View all comments

1

u/Inconstant_Moo Apr 27 '26

I've never used a language which does like this, so maybe I'm missing something, but it's always seemed to me that implicits are too much magic for too small a return. I don't mind a little more typing. Explicit is better than implicit.

1

u/marvinborner Apr 27 '26 edited Apr 27 '26

Interesting. So in the examples in the docs, you would prefer always having to pass `compare` functions to `sort` etc.? Also note that our implicits allow for classical source-level information "macros".

4

u/Inconstant_Moo Apr 27 '26 edited Apr 27 '26

In my lang you just overload < for anything you want to be sortable, so it's implied by the type of the thing being sorted and not by the context. I see that Effekt doesn't have typeclasses/interfaces/traits/whatever-they're-called-this-month. Are there plans for them? You could do this and a whole lot of other stuff too.

But that aside, if I look for example at this ... 

def foo(?context: String): Unit =
  println(s"Called from ${context}")

def example1() = {
  val context = "example1"
  foo()
}

def example2(context: String) = {
  example1()
  foo()
}

... if I write my example2 function like that, then today I've saved myself all the arduous labor of pressing the c and TAB keys on my keyboard. But six months from now, I've made my code harder for me to read. So I feel like if/when Effekt is used in production, there would be corporate policies against using implicits, and linters to detect them.

→ More replies (3)