Haskell: -fglasgow-exts ¿debería uno evitar el código que requiere esto?

Question

Soy un principiante con Haskell y he empezado a ver los errores similares a:

Illegal parallel list comprehension: use -fglasgow-exts 

estoy trabajando dentro ghci y con ghc pero sólo debido al hecho de que fue la primera que encontré en una búsqueda .

Tengo curiosidad si este es el tipo de situación que uno querría evitar seguir adelante. Todas las búsquedas que he aparecido mencionan que estas extensiones exponen las instalaciones subyacentes que pueden (o no) ser útiles.

Un ejemplo específico es

fibs = 0 : 1 : [ a + b | a <- fibs | b <- tail fibs ] 

supongo que el hecho de que tanto a y b están leyendo de la lista a la vez causa problemas aquí ...? Entonces, si las extensiones glasgow son el único medio para soportar esta construcción, ¿es más común generar la lista de otra manera o simplemente asumir que las extensiones estarán disponibles?

Gracias de antemano por cualquier entrada.

[EDITAR] Lo siento si esto no estaba del todo claro, pero mi pregunta es si la inclusión de extensiones de glasgow (o cualquier otra) se considera una mala práctica. El ejemplo anterior fue solo para ilustrar el tipo de error que provocó esta pregunta.

Answer 1

En lugar de solicitar todos extensiones de GHC, especifique cuáles son utilizados mediante el mecanismo de LANGUAGE pragma:

{-# LANGUAGE ParallelListComp #-} 
xy = [ x+y | x <- [1, 2, 3, 4] | y <- [5, 6, 7, 8] ] 

supongo que el hecho de que tanto a y b leyendo de la lista de la mismo tiempo causa problemas aquí ...? Entonces, si las extensiones glasgow son los únicos medios para soportar esta construcción ¿es más común generar la lista de otra manera o simplemente asumir que las extensiones estarán disponibles?

Se permite la iteración paralela en la misma lista. El problema es que las comprensiones paralelas no están definidas en el estándar Haskell 98. Ellos pueden simularse fácilmente usando zip:

xy = [x+y | (x,y) <- zip [1, 2, 3, 4] [5, 6, 7, 8]] 

extensiones de sí mismos no son malos - gran parte de la biblioteca estándar utiliza extensiones, de un tipo u otro. Muchos están siendo considerados para su inclusión en Haskell', la próxima iteración del estándar Haskell.Algunas extensiones, como las GADT, se usan comúnmente en las bibliotecas escritas por el usuario. Otros, como las plantillas o las instancias incoherentes, probablemente no sean una buena idea para utilizar a menos que realmente sepa lo que está haciendo.

Cualquier extensión enumerada en el HaskellExtensions wiki page con soporte de dos o más compiladores es probablemente segura de usar.

Answer 2

GHC es definitivamente omnipresente, creo que es el compilador Haskell más utilizado, por lo que probablemente no cause demasiados problemas. Sin embargo, siempre debería intentar escribir un código que cumpla con los estándares, tal vez no para proyectos personales, sino para OSS o de trabajo, definitivamente.

Todo puede pasar, ¿no? Entonces, ¿puede un cambio repentino en el compilador a la mitad de su proyecto?

Con OSS, diferentes personas usan compiladores diferentes - HUGS también es bastante común, por ejemplo.

Answer 3

Lo que quiere decir:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs) 

Esto se debe a las listas por comprensión realmente no funcionan con listas autorreferenciales. Además, aunque GHC es más popular, HUGS generalmente produce mensajes de error más claros.

Answer 4

Usar extensiones es correcto. Marcarlos específicamente con -XFoo o LANGUAGE FOO. Qué extensiones eliges usar son tu decisión, es posible que quieras apegarte a las que figuran para su inclusión en Haskell Prime.

Answer 5

Iba a sugerir el uso de un "," en lugar del "|", pero luego supe que esto hace algo más de lo que esperaba.

Por lo tanto, además de la portabilidad, también debe considerar la legibilidad. El uso de extensiones poco comunes puede hacer que su código sea más difícil de leer (para personas que no están familiarizadas con las extensiones).

Algunas extensiones no tienen ningún efecto negativo en la legibilidad (el código resultante es obvio), como MultiParamTypeClasses, FlexibleContexts, FlexibleInstances.

Otros requieren del lector una familiaridad con una nueva sintaxis y una comprensión de lo que significa esta sintaxis. Ejemplos de ellos serían ParallelListComp, TypeFamilies, FunctionalDependencies. En este caso, recomendaría intentar evitar estas extensiones a menos que traigan un beneficio. En este caso, puede usar zip como sugirió John Millikin, o refactorizar el código como desconocido.

sugerencia de +1 dons sobre el uso de los que se planean incluir en Haskell Prime.

Haskell 2010 es que se publicará a finales de 2009. El conjunto de cambios a introducir se darán a conocer en el Simposio Haskell, 3 de septiembre de 2009.