Haskell: -fglasgow-exts should one avoid code that requires this?

Question

I am a beginner with Haskell and I've started seeing errors similar to:

Illegal parallel list comprehension: use -fglasgow-exts

I am working within ghci and with ghc but only due to the fact that it was the first one I found on a search.

I'm curious if this is the type of situation one would want to avoid moving forward. Any searches I've turned up mention that these extensions expose underlying facilities that may (or may not) be useful.

A specific example is

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

I assume the fact that both a and b are reading from the list at the same time causes problems here...? So, if the glasgow extensions are the only means to support this construct is it more common to generate the list another way or just assume that the extensions will be available?

Thanks in advance for any input.

[EDIT] Sorry if this was not entirely clear, but my question is if including glasgow (or any other) extensions is considered bad practice. The example above was just to illustrate the type of error that prompted this question.

Answer 1

GHC is definitely pervasive - I think its the most-used Haskell compiler, so it probably won't cause too much trouble. You should always try to write standards-compliant code, though - maybe not for personal projects, but for OSS or work ones, definitely.

Anything can happen, right? So can a sudden change in compiler half-way through your project.

With OSS, different people use different compilers - HUGS is also quite common, for example.

Answer 2

Instead of requesting all GHC extensions, specify which ones are used using the LANGUAGE pragma mechanism:

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

I assume the fact that both a and b are reading from the list at the same time causes problems here...? So, if the glasgow extensions are the only means to support this construct is it more common to generate the list another way or just assume that the extensions will be available?

Parallel iteration over the same list is allowed. The problem is that parallel comprehensions are not defined in the Haskell 98 standard. They can be easily simulated using zip:

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

Extensions themselves are not bad -- much of the standard library uses extensions, of one sort or another. Many are being considered for inclusion in Haskell', the next iteration of the Haskell standard. Some extensions, such as GADTs are commonly used throughout user-written libraries. Others, such as templates or incoherent instances, are probably not a good idea to use unless you really know what you're doing.

Any extension listed in the HaskellExtensions wiki page with support from two or more compilers is probably safe to use.

Answer 3

What you want is:

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

This is because list comprehensions don't really work with self-referential lists. Also, although GHC is more popular, HUGS generally produces clearer error messages.

Answer 4

Using extensions is fine. Flag them specifically with -XFoo or LANGUAGE FOO. Which extensions you choose to use are up to you, you might want to stick to those listed for inclusion in Haskell Prime.

Answer 5

I was going to suggest using a "," instead of the "|", but then I learned this does something else than I expected.

So in addition to portability, you should consider readability too. Usage of uncommon extensions may make your code more difficult to read (for people who are unfamiliar with the extensions).

Some extensions don't have any negative effect on readability (the resulting code is obvious), like MultiParamTypeClasses, FlexibleContexts, FlexibleInstances.

Others require from the reader a familiarity with a new syntax and an understanding of what this syntax means. Examples for those would be ParallelListComp, TypeFamilies, FunctionalDependencies. In this case, I would recommend to try to avoid these extensions unless they bring a benefit. In this case you can just use zip as John Millikin suggested, or refactor the code as unknown suggested.

+1 dons' suggestion on using those planned to be included in Haskell Prime.

Haskell 2010 is due to be released in late 2009. The set of changes to be incorporated will be announced at the Haskell Symposium, September 3 2009.