我是Haskell的初学者，我开始看到类似的错误：
Illegal parallel list comprehension: use -fglasgow-exts
我在ghci和ghc内工作，但这只是因为它是我在搜索中找到的第一个。
我很好奇这是否是一种人们希望避免前进的情况。我发现的任何搜索都提到这些扩展会暴露可能（或可能不）有用的基础设施。
一个具体的例子是
fibs = 0 : 1 : [ a + b | a <- fibs | b <- tail fibs ]
我认为a和b同时从列表中读取会导致问题......那么，如果格拉斯哥扩展是支持这种结构的唯一方法，那么更常见的是以另一种方式生成列表，或者只是假设扩展可用？
提前感谢任何输入。
[编辑] 对不起，如果这还不完全清楚，但我的问题是，如果包括格拉斯哥（或任何其他）扩展被认为是不好的做法。上面的例子只是为了说明提示这个问题的错误类型。
答案 0 :(得分：12)
不是请求所有 GHC扩展，而是使用LANGUAGE pragma机制指定使用哪些扩展名
{-# LANGUAGE ParallelListComp #-}
xy = [ x+y | x <- [1, 2, 3, 4] | y <- [5, 6, 7, 8] ]
我假设
a和。{b正在从列表中读取 同时在这里引起问题......？所以， 如果格拉斯哥扩展是唯一的 是否支持这种结构 更常见的是生成列表 另一种方式或只是假设 扩展程序可用吗？
允许在同一列表上进行并行迭代。问题是并行理解没有在Haskell 98标准中定义。可以使用zip：
xy = [x+y | (x,y) <- zip [1, 2, 3, 4] [5, 6, 7, 8]]
扩展本身并不错 - 标准库中的大多数都使用某种或那种扩展。许多正被考虑包含在Haskell'中，这是Haskell标准的下一次迭代。一些扩展（例如GADT）通常在用户编写的库中使用。其他的，比如模板或不连贯的实例，可能不是一个好主意，除非你真的知道你在做什么。
HaskellExtensions wiki page中列出的任何扩展程序都有两个或更多编译器的支持，可以安全使用。
答案 1 :(得分：6)
GHC绝对是普遍的 - 我认为它是最常用的Haskell编译器，所以它可能不会造成太多麻烦。不过，您应该总是尝试编写符合标准的代码 - 可能不是针对个人项目，而是针对OSS或工作代码。
任何事情都可能发生，对吧？编译器中途可能会突然改变你的项目。
使用OSS，不同的人使用不同的编译器 - 例如，HUGS也很常见。
答案 2 :(得分：6)
使用扩展程序很好。使用-XFoo或LANGUAGE FOO标记它们。 您选择使用哪些扩展程序取决于您，您可能希望坚持列入包含在Haskell Prime中的扩展程序。
答案 3 :(得分：3)
你想要的是：
fibs = 0 : 1 : zipWith (+) fibs (tail fibs)
这是因为列表推导并不真正适用于自引用列表。此外，虽然GHC更受欢迎，但HUGS通常会产生更清晰的错误消息。
答案 4 :(得分：1)
我打算建议使用“,”而不是“|”，但后来我知道这样做的事情超出了我的预期。
因此除了可移植性之外，您还应该考虑可读性。使用不常见的扩展可能会使您的代码更难以阅读（对于不熟悉扩展的人）。
某些扩展程序对可读性没有任何负面影响（结果代码很明显），例如MultiParamTypeClasses，FlexibleContexts，FlexibleInstances。
其他人要求读者熟悉新语法并理解这种语法的含义。这些示例包括ParallelListComp，TypeFamilies，FunctionalDependencies。在这种情况下，我建议尽量避免这些扩展，除非它们带来好处。在这种情况下，您可以像John Millikin建议的那样使用zip，或者将代码重构为未知的建议。
+1 dons'建议使用计划包含在Haskell Prime中的那些。
Haskell 2010将于2009年底发布。将于2009年9月3日在Haskell Symposium上宣布将要合并的一系列变更。