[ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept

Joachim Breitner mail at joachim-breitner.de
Wed May 19 07:41:23 UTC 2021

Hi Eric,

I agree that this proposal is really two proposals that are relatively
orthogonal (defaults for other type classes, and defaults across
modules). Worth splitting maybe?

Following your recommendation, focusing on NamedDefaults first.

Indeed, if he had the ability to write

  default IsString (T.Text)

I might have voted OverloadedStrings into Haskell2021 :-)

So definitely a valuable proposal, but I think we some questions are
unanswered yet.

   default A (Int,String,())
   default B (String,(),Int)
   (A t, B t) => t
it says “just don't do that;”.

But doesn’t that imply that, if one wants to rule out all use-site
conflicts, there must be a global priority ordering of types across all
defaultable type classes where each individual default clause is a
subsequence of? Would it then make sense to just statically forbid such
“illegal” orderings, i.e. reject if two default declarations are in
scope that could lead to that? Would that rule out declarations that
we’d want to allow?

And then there are the multi-parameter type classes… they are discussed
in the end, but not part of the proposal.
I kinda feel that instead of taking one small step here, we should aim
a bit higher and find something that works not just for some type
classes, but most of them out there. Or at least understand why that
would not be possible/desirable.

That said, I don’t consider myself an expert on type class defaulting,
so happy to hear other’s opinions here.


Joachim Breitner
  mail at joachim-breitner.de

More information about the ghc-steering-committee mailing list