"불가능한"경우에도 하스켈에서 철저한 패턴 매칭을 항상하는 것이 좋습니까?

Question

"불가능한"경우에도 하스켈에서 철저한 패턴 매칭을 항상하는 것이 좋습니까?

예를 들어, 다음 코드에서 foldr의 "누적 기"에 패턴 일치가 있습니다. 누적 기의 내용을 완벽하게 제어합니다. 생성하기 때문에 (입력으로 전달되지 않고 내 함수 내에서 생성됩니다). 따라서 특정 패턴이 절대로 일치해서는 안된다는 것을 알고 있습니다. "Pattern match (es) is non-exhaustive"오류가 발생하지 않도록 노력한다면 패턴 일치를 배치하여 "이 패턴은 발생하지 않아야합니다."라는 메시지와 함께 오류가 발생합니다. C#의 주장과 매우 ​​비슷합니다. 나는 그곳에서 할 일을 생각할 수 없다.

이 상황에서 어떤 연습을 권하고 싶습니까? 그 이유는 무엇입니까?

gb_groupBy p input = foldr step [] input 
    where 
     step item acc = case acc of 
      []       -> [[item]] 
      ((x:xs):ys)     -> if p x item 
              then (item:x:xs):ys 
              else [item]:acc 

(인터프리터에 의해보고) 일치하지 않는 패턴은 다음과 같습니다 :

경고 : 패턴 일치 (들) 경우의 대안 비 철저한 있습니다 : 패턴 여기

코드입니다 일치하지 않음 : [] : _

Answer 1

이것은 아마도 다른 어떤 것보다 스타일의 문제 일 것입니다.

이

gb_groupBy p input = foldr step [] input 
    where 
    step item acc = case acc of 
     []       -> [[item]] 
     (xs:xss)      -> if p (head xs) item 
             then (item:xs):xss 
             else [item]:acc 

패턴 매칭은 다음과 같습니다 경고 : 당신은이 작업을 수행하여이 특별한 경우에 경고를 해결할 수 있습니다

Answer 2

침묵하는 경우에만 개인적으로, 나는

_ -> error "Impossible! Empty list in step" 

에 둘 것 그리고 나서 완료되고 누적 기 헤드의 빈 목록의 "불가능한"조건은 런타임 오류를 발생 시키지만 경고는 발생시키지 않습니다.

불완전한 패턴 매치의보다 일반적인 문제를 보는 또 다른 방법은 "코드 냄새"로 보는 것입니다. 즉, 차선책 또는 비 하스켈 식으로 문제를 해결하려고한다는 표시입니다. , 우리의 기능을 다시 쓰려고 노력하십시오.

foldr을 사용하여 groupBy를 구현하면 무한한 목록에 적용 할 수 없으며, 이는 하스켈 목록 함수가 의미 상으로 합리적인 곳에서 달성하려고하는 디자인 목표입니다. 고려하십시오

take 5 $ groupBy (==) someFunctionDerivingAnInfiniteList 

처음 5 개 그룹이 w.r.t. 평등은 유한이며 게으른 평가는 종료됩니다. 이것은 엄격하게 평가 된 언어로는 할 수없는 일입니다. 당신이 무한리스트와 함께 작동하지 않는 경우에도, 다음과 같은 기능을 작성하는 것은 긴 목록에 더 나은 성능을 얻을, 또는 List.hs에서

take 5 $ gb_groupBy (==) [1..1000000] 

, GROUPBY는 다음과 같이 구현과 같은 식을 평가할 때 발생하는 스택 오버 플로우를 방지 할 수 있습니다 :

groupBy   :: (a -> a -> Bool) -> [a] -> [[a]] 
groupBy _ []  = [] 
groupBy eq (x:xs) = (x:ys) : groupBy eq zs 
          where (ys,zs) = span (eq x) xs 

이 결과는 필요한 계산의 부분을 평가하는 인터프리터/컴파일러 수있다. span은 첫 번째가 술어를 만족하는 목록의 헤드에서 (연속적인) 요소로 구성되고 두 번째가 목록의 나머지 부분 인 한 쌍의 목록을 생성합니다. 그것은 또한 무한한 목록에서 작동하도록 구현되었습니다.

Answer 3

필자의 이전 의견을 확인하기 위해 누락 된 사례를 확인했지만 파일/줄 번호와 관련된 유용한 오류가 표시된다는 것을 알았습니다. 그래도 최적화되지 않은 빌드에만 표시되기 때문에 이상적이지 않습니다 (here 참조).

... 
[]:xs -> assert False (error "unreachable because I know everything") 

Answer 4

케이스 패턴에 대한 철저한 검사가 빠뜨릴 수 없습니다. _이 모든 것을 매칭하기 때문에 최상위 레벨의 케이스에서는 결코 _을 사용하지 않으려 고 노력합니다. 그리고이를 사용하여 완전성 검사의 가치를 저하시킵니다. 목록에서는 중요하지 않지만 사용자 정의 대수 데이터 형식에서는 매우 중요합니다. 새 생성자를 추가하고 누락 된 모든 경우에 컴파일러 barf를 사용할 수 있기를 원하기 때문입니다. 이런 이유로 나는 항상 -Werror을 켜고 컴파일하므로, 사건을 빠뜨릴 수는 없습니다. 관찰

, 코드가

[] : _ -> error "this can't happen" 

내부적으로이 경우 확장 할 수 있습니다, GHC는 error 달리 소스 좌표를 줄 것이다 panic 기능을 가지고 있지만, 나는 구현을 보면서 머리를 만들 수 없습니다 또는 그것의 꼬리.

Answer 5

유형 시스템은 친구이며 경고는 귀하의 기능에 균열이 있음을 알려주는 것입니다. 가장 좋은 방법은 형식간에보다 깔끔하고 우아한 느낌을주는 것입니다. 보기의

groupBy     :: (a -> a -> Bool) -> [a] -> [[a]] 
groupBy _ []   = [] 
groupBy eq (x:xs)  = (x:ys) : groupBy eq zs 
          where (ys,zs) = span (eq x) xs 

Answer 6

내 포인트가 불가능한 경우 정의되지 않은 점이다 :

는 groupBy의 GHC의 정의를 생각해 보자.
정의되지 않은 경우 우리는이 함수를 사용할 수 있습니다. 교묘하게도 undefined입니다.

_ -> undefined 

을 그리고 거기 당신은 그것이있다 :

의 좋아하여 일치를 완료!