#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Differential Revisions: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: #4259 | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:40 goldfire]:

I'm still not sold on the concrete syntax involving `result`, despite having introduced that idea myself. I like the `(**)` suggestion here a bit more: http://www.haskell.org/pipermail/ghc-devs/2014-July/005492.html

So, to be precise, with this syntax the examples from the wiki page would look like this: {{{ type family F a b c | F -> a b c type family G a b c | G -> a b type family H a b c | H a -> b c, H b -> a c, H c -> a b type family J a b c | J a -> b c, J b -> a c }}} I did not propose to use the notation like `H b -> a c` because I thought it might mislead people to think that: a) `H` could be partially applied; b) some parameters of `H` could be skipped (ie. we can apply it to `b` without first applying to `a`). Luckily, this is not a blocking issue for the rest of implementation. It should only affect 3 files in the parser, so it can be changed later.

Separately, a change to Core will be necessary to really make this work in all cases.

(...)

All that said, this use case is obscure, and the primary push for injective type families does not seem to require a change to Core. It is worth implementing without this piece. But, the idea came up in conversation, and I thought I should record it.

This is beyond my knowledge - I would require some guidance here. But if it's possible to implement injective type families without this change then I would postpone it until later and possibly consider it a separate task. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/6018#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler