2011-12-03 3 views
13

내 코드에서 모든 최상위 수준 정의에 대해 형식 시그니처를 넣는 것을 좋아합니다. 그러나 인스턴스 선언의 형식 시그니처는 허용되지 않는 것 같고, 하나를 넣으면 GHC에서 "잘못 배치 된 형식 시그니처"오류가 발생합니다. 이게 왜 그렇게? GHC에서 형식 서명이 기대했던 것과 동일한 지 확인하지 못하고 왜 형식 서명이 일치하지 않는지 거부 (또는 경고) 할 수없는 이유는 무엇입니까?하스켈의 인스턴스 선언에 형식 시그니처를 넣을 수없는 이유는 무엇입니까?

+3

[내가 열어 본 티켓] (http://hackage.haskell.org/trac/ghc/ticket/5676) SPJ는 다음과 같이 설명했습니다. "[인스턴스 선언에 형식 서명을 원했습니다.] 그래서 저는 여분의 순간에 그것을했다. " 그는 현재 GHC 7.6에 이정표를 세웠지 만, GHC 7.4에 들어가게 될 약간의 기회가있다. 이 질문에 감사드립니다! Daniel Fischer, 감사합니다. 티켓을 제안합니다. –

답변

10

형식 선언을 원할 경우 인스턴스 본문 외부에서 함수를 별도로 만들 수 있습니다.

class Class a where 
    f1 :: a -> a 

instance Class Foo where 
    f1 = foo_f1 

--monomorphic version of f1 for Foo: 
foo_f1 :: Foo -> Foo 
foo_f1 = ... 
4

서명은 클래스 정의의 일부이므로 인스턴스 선언의 유형 서명은 중복 서명이됩니다. 나는 원칙적으로 중복 서명을 허용하는 데 문제가 있다고 생각하지 않지만 일반적으로 서명을 허용하는 데는 이점이 없으며 서명을 허용하지 않는 것이 더 간단합니다. 그래서 언어 정의에 따르면 엔티티 당 최대 하나의 유형 서명이있을 수 있습니다. 인스턴스 선언에서도 서명을 허용하는 기능은 많이 요구되지 않았기 때문에 확장을 허용하지 않습니다. 정말로 원하면 GHC trac에서 기능 요청을 제기 할 수 있습니다. 충분한 관심을 얻으면 구현 될 수 있습니다 (그러나 수요가 높을 것으로 기대하지는 않습니다).

+1

장점은 GHC가 서명을 확인하는 것입니다. 프로그래머는 형식 서명에 대한 자신의 신념을 주장 할 수 있고, 확인하고 잘못한 경우에 포착 할 수 있습니다. – Prateek

+1

@Prateek 컴파일러는 클래스의 서명과 대조하여 컴파일러에서이를 확인합니다. 클래스 정의의 인스턴스를 제외한 모든 시그니처는 인스턴스 유형으로 대체 된 관련 유형 변수와 함께 거부되어야하므로 추가 정보 나 안전성을 제공 할 수 없습니다. 코드를 읽는 독자에게는 약간의 추가 문서가 될 것입니다 (나쁜 것은 아니지만 의견에 서명을하여이를 달성 할 수 있습니다. 유형이 분명하고 잘 알려지지 않았다고 생각하면 그렇게합니다.)). –

+4

나는 프로그래머가 서명을 믿는 것에 대해 확인하는 것을 의미했다. 이것은 추가적인 안전성을 부여하지 않습니다. 그러나 더 이해하기 쉬운 오류 메시지를 줄 수 있습니다. "다른 형식의 오류 대신 형식 서명이 X라고 생각하지만 실제로 Y입니다." 또한 프로그래머는 형식 선언 내부에 주석을다는 특수한 경우를 작성하는 대신 형식 선언을 작성하는 통일 된 스타일을 채택 할 수 있습니다. – Prateek

3

어떤 경우이든 유형이 중복되고 일반적으로 중복을 피하려고합니다. Frege에서 인스턴스 구성원에 대한 유형 시그니처를 쓸 수 있습니다. 그들은 확인 된 다음 버려집니다. 그것은 당연히 그들을 금하는 것이 더 쉽습니다.

+2

중복성이 좋은 경우가 있습니다. – ThePiercingPrince

11

[새 항목] -XInstanceSigs을 사용하여 인스턴스의 유형 시그니처를 추가 할 수 있습니다.이 유형 시그니처는 범위에 유형 변수를 가져 오는 데 특히 유용합니다. 자세한 내용은 official docs에서 확인할 수 있습니다.

관련 문제