Can you elaborate? I don't understand where you are coming from yet.

In haste,

• Many open tickets about fundeps… still open because of lack of agreement about what the Right Thing is, not because the implementation is difficult
• As originally proposed they are quite restrictive (the Coverage Condition).  Many uses of fundeps use a more liberal coverage condition, currently enabled by UndecidableInstances.  I’m not sure if “Many” means “most” or just “a minority”; data needed.
• Fundeps affect unification in type inference, and have no effect in Givens, unlike type families. Nothing inherently wrong with that, but it feels unsatisfying that we can know that t1~t2 (from a fundep between two givens) but can’t exploit that fact.

They are undoubtedly useful. I’m not arguing for removal.  They have just never felt as solid to me as other parts of our type system.

Simon

From: Spiwack, Arnaud <arnaud.spiwack@tweag.io>
Sent: 04 December 2020 14:13
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: GHC Steering Committee <ghc-steering-committee@haskell.org>
Subject: Re: [ghc-steering-committee] #380 GHC2021: What's wrong with Functional dependencies

On Fri, Dec 4, 2020 at 3:07 PM Simon Peyton Jones <simonpj@microsoft.com> wrote:

But fundeps – because they don’t carry evidence, as they stand – feel less solidly rooted.

Can you elaborate? I don't understand where you are coming from yet.

(for the record: I'm not applying just “guarded by their own syntax” as a criterion, for me, this criterion is a sufficient condition for “no surprising new errors”. I also believe (believed?) that functional dependencies were quite standard and expected them to be here forever. I took TypeFamilyDependency to be a mild extension. I'm perfectly willing to be convinced otherwise.)