Skip to content
0:00 / 0:00

#scala#implicits#scala3

Keynote: Some Mistakes We Made When Designing Implicits – Martin Odersky

Typelevel

2.6K subscribers • 3 videos on Hallway

YouTube
  • Recommended by 1 person: 1 in engineering communities.
  • Presented by Martin Odersky, professor at EPFL

Intermediate. Assumes working knowledge.

4.1K views7 years ago1 recommendation

Programming languagesScalaLanguage design and type systems

Martin Odersky discusses the history and evolution of implicits in Scala, the design mistakes made, and how Scala 3 addresses them.

We will talk about the history how Scala's implicits evolved, and about some of the mistakes we could have avoided in hindsight, but also about things that I believe we got right. I'll conclude with a presentation of revised implicits in Scala 3 which fixes most of the current problems and hopefully does not create too many new ones. * Event * Typelevel Summit Lausanne, June 2019: typelevel.org/event/2019-06-summit-lausanne/ * About Speaker * Martin Odersky is professor at EPFL, coordinating the LAMP group. * Licensing * This recording is licensed under CC-BY 4.0 (creativecommons.org/licenses/by/4.0/).

Why it's here

1 person recommends this

u/bjzabaPikelet, Unnamed Binary DDLin r/ProgrammingLanguages • Recommends

Keynote: Some Mistakes We Made When Designing Implicits – Martin Odersky

u/curtisfin r/ProgrammingLanguages • Mentions

On “Any idea how to solve the orphan instance problem?”

I think I like Scala's solution to this problem. Typeclasses "really" are just dictionaries of functions; the primary reason you want to bake them into the language is because passing them around is inconvenient. Scala fixes this by making a language feature, implicits, that automatically passes objects for you. (Having a canonical instance is also potentially helpful to avoid, e.g., passing different comparators into a tree data structure over time, but this can also usually be avoided by closing-over the one instance that you care about at creation time) Haskell's typeclasses have some limitations. The principle difficulty is that you can't have multiple implementations of a typeclass f…