Haskell에 ML 스타일 모듈을 추가하는 데있어 가장 큰 이론적 어려움은 무엇입니까?

Haskell에 ML 스타일 모듈을 추가하는 데있어 가장 큰 이론적 어려움은 무엇입니까?

---

Haskell 스타일 유형 클래스와 ML 스타일 모듈은 인터페이스 를 지정하기위한 다른 메커니즘을 제공한다는 것은 잘 알려져 있습니다 . 그들은 (아마도) 권력이 동등하지만 실제로는 각각 고유 한 장점과 단점이 있습니다.

언어 기능에 관해서는 약간의 포용 주의자이기 때문에 내 질문은 다음과 같습니다. Haskell에 ML 스타일 모듈을 추가하는 데있어 가장 큰 이론적 어려움은 무엇입니까? 다음 줄에 대한 답변에 관심이 있습니다.

• ML 스타일 모듈과 제대로 상호 작용하지 않는 기존 유형 시스템 기능은 무엇입니까? (저조한 상호 작용의 예는 Fundeps이 관련 유형과 기술적으로 동일하더라도 GADT 및 기능적 종속성입니다!)

• ML 스타일 모듈을 컴파일하기 위해 컴파일러 측에서 포기해야하는 것은 무엇입니까?

• ML 스타일 모듈은 유형 추론과 어떻게 상호 작용합니까?

관련 자료 :

• 이 질문을 유발 한 Robert Harper의 게시물
• Haskell Reddit에 대한 토론

---

비교를 수행하는 주요 장소는

• ML 모듈 및 Haskell 유형 클래스 : 건설적인 비교 . Stefan Wehr 및 Manuel MT Chakravarty. 프로그래밍 언어 및 시스템에 관한 제 6 회 ASIAN 심포지엄-APLAS 2008, Springer-Verlag, LNCS, 2008.

• 모듈 형 클래스 . Derek Dreyer, Robert Harper 및 Manuel MT Chakravarty. 제 34 회 ACM SIGPLAN-SIGACT 프로그래밍 언어 원칙 심포지엄, ACM Press, 2007.

• Haskell , Mark Shields 및 Simon Peyton Jones를 위한 1 급 모듈 . 오레곤 주 포틀랜드에있는 객체 지향 언어의 기초에 관한 제 9 회 국제 컨퍼런스 (FOOL 9)에 제출되었습니다. 20 페이지. 2001 년 10 월.

나는 이론적 인 문제를 실제로 알지 못합니다. 적어도 구체적인 제안이 이루어졌고 프로토 타입으로 구현되었습니다. Shields와 PJ 논문에는 많은 세부 사항이 있습니다. 그러나 구현 부담은 사소하지 않습니다.

---

큰 이론적 문제는 없다고 생각합니다. 적용 가능한 펑터에 대한 결정을 내려야합니다. Applicative는 아마도 Haskell 스타일에 더 가깝습니다. 하지만 ML 스타일 모듈을 Haskell에 추가하려는 시도는 모듈과 클래스가 겹치기 때문에 기괴 할 것이라고 생각합니다. 많은 일을하는 두 가지 방법이 있습니다.

---

Simon PJ는 ML 스타일 모듈의 전력 / 비용 비율이 낮고 구현하기 어렵다고 주장했습니다. POPL 2003 (끝까지) 의 SPJ 슬라이드를 참조하십시오 . 그는 또한 더 나은 전력 / 비용 배급을 가진 디자인을 요구하지만 나는 그러한 제안을 알지 못합니다.

참고 URL : https://stackoverflow.com/questions/5695055/what-are-the-primary-theoretical-difficulties-with-adding-ml-style-modules-to-ha