Why not implicit parameters?

Learn
15

Implicit parameters suffer from various problems:

  • The parameters are just Symbols living in the global namespace. This means that abstraction is impossible and there is a risk of name clashes.

  • If a parameter has been bound multiple times, understanding which one “wins” is not straightforward, except in the simplest cases.

  • Parameters don’t get along well with the monomorphism restriction. Chris Done’s post shows an example of this problem.

  • Implicit parameters are implemented by piggybacking on type classes, which have been designed for static, global resolution. GHC’s code base is full of ad-hoc checks and special cases to force the IP class to behave as expected and forbid setting it as a superclass (which would break global coherence). In hindsight, IP should probably be a different kind of constraint.

That being said, conceptually I prefer implicit parameters to Reader because they are more composable (incidentally I am working on a library that solves the first two problems).

5 Likes