{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifvxkdu6t2lu6cb5uz5voeptwkigdhk3w437adw3oomeckjvqxdnm",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjelptbcc462"
  },
  "path": "/t/type-level-programming-dealing-with-ambiguous-type-error/13828#post_9",
  "publishedAt": "2026-04-13T09:10:23.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I didn’t narrow it down to something specific, but I dropped it as being trouble compared to `Proxy` for not much gain.\n\nI expect my code to compile warning-free. When using variables introduced by `forall n ->`, I found trying to juggle the variables introduced in the type signature and in the pattern match, with type applications/inline type signatures, I seemed to always have either an undeclared or an unused variable. Something like, a function wouldn’t compile without a variable being included in `forall n.`, but when I did include it, I got an unused type variable warning. I just gave up and switched to proxies.\n\nHaving said that, there is a feature of `RequiredTypeArguments` that I do like. Until now, the only way to go from `type (or data kind) -> term` was with a typeclass. this has the disadvantage of a) unwieldly syntax (for this use case) and b) It doesn’t support closed classes. By RTA allows me to pattern-match on types in function syntax, which is nice. So I may well come back to them someday and settle my differences properly.",
  "title": "Type level programming: Dealing with ambiguous type error"
}