Cabal-syntax: trade TypeFamilies for FunctionalDependencies

[Bodigrim]

The overarching goal is to make Cabal-syntax compilable by MicroHs, which does not support TypeFamilies, but does support FunctionalDependencies. See #11341 for more context.

The only type family Cabal uses is

class Ord (Key a) => IsNode a where
  type Key a
  nodeKey :: a -> Key a
  nodeNeighbors :: a -> [Key a]

This PR changes it to

class Ord keyA => IsNode keyA a | a -> keyA where
  nodeKey :: a -> keyA
  nodeNeighbors :: a -> [keyA]

Ignoring my original motivation for a moment, I think type families do not really bear their weight for class IsNode. Fundeps are more explicit and better to work with: I don't need to evaluate type Key in my head to figure out what's exactly the key, it's right there in type signatures now.

I'll update changelog once this passes CI.

Template Α: This PR modifies behaviour or interface

Include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
  • Is the change significant? If so, remember to add significance: significant in the changelog file.
• The documentation has been updated, if necessary.
• Manual QA notes have been included.
• Tests have been added. (Ask for help if you don’t know how to write them! Ask for an exemption if tests are too complex for too little coverage!)

[ffaf1]

Performance issues aside, I find type families easier to understand and reason about than functional dependencies. I believe both researchers and implementators meant type families to replace (among other things) functional dependencies.

Supporting a new compiler is a worthy goal, not a cheap one.
If a decision is made to suppot MicroHs, I would expect a list of allowed/disallowed extensions in CONTRIBUTING.md (or even better, new CI runners).

[geekosaur]

Hlint can blacklist extensions, fwiw.

[ulysses4ever]

in the light of #11341 (comment) I suggest to close this PR. In general, I prefer TF over FD for the reason Francesco mentioned: I think they're miles more user-friendly.

[geekosaur]

I'm slightly in favor of type families.

That said, I should note that multiple Haskell language committees have deadlocked on the question of whether FDs or TFs are the better approach (in the context of standardizing MPTCs); it's not as straightforward as @ffaf1 suggested.

[Bodigrim]

Performance issues aside, I find type families easier to understand and reason about than functional dependencies. I believe both researchers and implementators meant type families to replace (among other things) functional dependencies.

I mean, there are ways to abuse functional dependencies for type-level computations like https://aphyr.com/posts/342-typing-the-technical-interview, which certainly gets much cleaner with type families (as in https://huwcampbell.com/posts/2017-05-11-8-queens-problem.html). But my experience is that type families are hard to maintain in the long run. I recently worked with an old codebase full of them - and it is a horrible maze unless you page it in enough to evaluate type equations by heart. Functional dependencies put all associated data types in front of you, which is more verbose and could be annoying to write, but so much easier to read 15 years later.

That said, I'd be happy to add HLint validation and whatever if there is enough interest in doing it, but I won't fight an uphill battle. Closing.