https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6#superclass-expansion-is-more-conservative
내가 9.4 -> 9.6 마이그레이션에서 겪고 있는 문제가 이거랑 관련이 있는거 같은데(확실치 않음)... 9.4에서는 c :: Type -> Constraint 일때 forall c. c Int 뭐 이런 조건이 있으면, 모든 c에 대해 c Int가 존재하는게 말이 안되는데도 실제로 c Int 꼴로 쓰이는 c만 고려해서 타입체크를 통과시켜줬던거 같다(이것도 확실하지 않음). 근데 9.6에선 당연히 거부당한다.
위의 내 이해가 맞다면 9.4의 constraint solving 완전 무근본이었단건데, 이건 또 믿기 어렵다(하스켈의 설계 결정에 대한 신뢰 유지한다고 하면). 어디서 내가 잘못 파악한거지.
If you have a fediverse account, you can reply to this note from your own instance. Search https://hackers.pub/ap/notes/01965c6f-35e9-7a69-8765-2d55adf9a9c8 on your instance and reply to it.
@bglbgl gwyng 어떤 코드에서 어떤 에러가 나나요?
@bglbgl gwyng 이 변화는 Paterson-smaller 제약들(Constraints), 즉 어떤 정렬 순서(Well-order)에 의해 더 작은 제약들만 확장하겠다는 확장 순서의 변화고, 이를 제외하면 양상자(quantifier)와의 상호작용은 크게 변하지 않았습니다. 따라서 설명하신 것과는 다른 방식으로 오류가 발생하게 되지 않았나 싶습니다.
@bglbgl gwyng 말씀하신 forall c. c Int 꼴이 instance head에 등장하는 건 아닐 거고 instance context나 superclass로 들어 오는 걸 텐데 그것도 instance (forall c. c Int) => ... 꼴이 아니라 instance forall c. c Int => ...이런 꼴이면 해당 변화랑 관계가 있을 여지가 있는 것 같네요. 물론 정확한 건 코드를 봐야 알거 같지만요.
9.6 migration 컴파일러 변화가 타입 패밀리, 슈퍼 클래스 관련 동작이 있네요. @bglbgl gwyng
