¿Se recomienda siempre tener coincidencias de patrones exhaustivas en Haskell, incluso para casos "imposibles"?

Question

¿Se recomienda siempre tener coincidencias de patrones exhaustivas en Haskell, incluso para casos "imposibles"?

Por ejemplo, en el siguiente código, estoy coincidiendo con el patrón en el "acumulador" de un foldr. Estoy en control total de los contenidos del acumulador, porque lo creo (no me lo pasa como entrada, sino que se construye dentro de mi función). Por lo tanto, sé que ciertos patrones nunca deberían coincidir. Si me esfuerzo por no obtener nunca el error "Patrón coincidente no es exhaustivo", entonces colocaría una coincidencia de patrón para él, simplemente error con el mensaje "Este patrón nunca debería ocurrir". Muy parecido a una afirmación en C#. No puedo pensar en otra cosa que hacer allí.

¿Qué práctica recomendaría en esta situación y por qué?

Aquí está el código:

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 

El patrón no coincide (según lo informado por el intérprete) es:

Advertencia: Coincidencia de patrón (es) no son exhaustivas En una alternativa caso: Patrones no coincide: []: _

Answer 1

Esto es probablemente más una cuestión de estilo que otra cosa. En lo personal, me gustaría poner en un

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

aunque sólo sea para silenciar el aviso :)

Answer 2

Puede resolver la advertencia en este caso especial, al hacer esto:

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 

La coincidencia de patrones es luego complete, y la condición "imposible" de una lista vacía en la cabecera del acumulador causaría un error de tiempo de ejecución pero no una advertencia.

Otra forma de ver el problema más general de los emparejamientos de patrones incompletos es considerarlos como un "olor a código", es decir, una indicación de que estamos tratando de resolver un problema de manera subóptima o no Haskellish y trata de reescribir nuestras funciones

Implementación de groupBy con un foldr hace que sea imposible aplicarlo a una lista infinita, que es un objetivo de diseño que las funciones de la lista Haskell intentan lograr siempre que sea semánticamente razonable. Considere

take 5 $ groupBy (==) someFunctionDerivingAnInfiniteList 

Si los primeros 5 grupos w.r.t. la igualdad es finita, la evaluación perezosa terminará. Esto es algo que no puedes hacer en un lenguaje estrictamente evaluado. Incluso si usted no trabaja con listas infinitas, escribiendo funciones como esto dará lugar a un mejor rendimiento en las listas largas, o evitar el desbordamiento de pila que se produce cuando la evaluación de expresiones como

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

En List.hs, GroupBy se implementa como esto:

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

Esto permite al intérprete/compilador para evaluar sólo las partes de la computación necesaria para el resultado. span produce un par de listas, donde la primera consiste en elementos (consecutivos) del encabezado de la lista que satisfacen un predicado, y el segundo es el resto de la lista. También se implementa para trabajar en listas infinitas.

Answer 3

Para dar seguimiento a mi comentario anterior, me di cuenta de que hay una manera de reconocer el caso perdido pero aún obtener un error útil con el número de archivo/línea. No es ideal, ya que solo aparecerá en versiones sin optimizar (ver here).

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

Answer 4

Encuentro la comprobación exhaustiva de los patrones de casos indispensables. Intento nunca usar _ en un caso en el nivel superior, porque _ concuerda con todo, y al usarlo invalida el valor de la verificación exhaustiva. Esto es menos importante con las listas pero es muy importante con los tipos de datos algebraicos definidos por el usuario, porque quiero poder agregar un nuevo constructor y tener la barra de compilación en todos los casos faltantes. Por esta razón, siempre compilo con -Werror encendido, por lo que no hay manera de que pueda omitir un caso.

Como se observa, el código se puede ampliar con este caso

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

Internamente, GHC tiene una función panic, que a diferencia de error dará las coordenadas de origen, pero yo miraba a la puesta en práctica y no podía hacer la cabeza o la cola de ella.

Answer 5

El sistema de tipos es su amigo, y la advertencia le indica que su función tiene grietas. El mejor enfoque es buscar un ajuste más limpio y elegante entre los tipos.

Considerar la definición de GHC de groupBy:

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

Mi punto de vista es que es un caso imposible indefinido.
Si no está definido, tenemos una función para él: el hábilmente llamado undefined.

Complete su coincidencia con los gustos de:

_ -> undefined 

Y ahí lo tienes!