Language extensions - backwards compatibility
I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards. GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether. Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor. The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything? -- Iain Alexander ia@stryx.demon.co.uk
ia:
I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards.
GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether.
Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor.
The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything?
Could you talk a bit about why you need to support 6.4 onwards -- that seems like quite a burden. Is the effort worth it?
On 28 Jan 2010 at 15:45, Don Stewart wrote:
Could you talk a bit about why you need to support 6.4 onwards -- that seems like quite a burden. Is the effort worth it?
Good question. The code was developed on 6.4, and I would really quite like to continue 6.4 support for personal reasons, if nothing else. But I would like to release it on Hackage eventually, so I really need to consider support for later releases. :-) In principle, I don't anticipate any portability problems, other than this practical one of managing the way the various versions of the compiler handle language extensions. Obviously, there may come a point where I cut 6.4 loose, and to some extent this depends on what sort of solution (if any) to this problem arises. -- Iain Alexander ia@stryx.demon.co.uk
On 28/01/10 23:38, Iain Alexander wrote:
I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards.
GHC 6.4 does not support the LANGUAGE pragma. Specifying language options in the OPTIONS_GHC pragma starts to produce deprecation warnings in 6.10, and will presumably eventually fail altogether.
Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.) Attempting preprocessing inside a leading OPTIONS_GHC pragma fails because it apparently attempts to interpret the pragma *before* invoking the preprocessor.
The only remaining option I can see is to have a completely separate version of the file for GHC 6.4. Have I missed anything?
There are a little cluster of bugs to do with this, see http://hackage.haskell.org/trac/ghc/ticket/3457 We need to re-read the pragmas after preprocessing. Ironically though, you will only be able to use this facility with a GHC that supports it, so we'll see a lot of source files like {-# LANGUAGE ... #-} #if __GLASGOW_HASKELL__ >= 614 {-# LANGUAGE .. more .. #-} #endif because GHC before 6.14 will stop at the first #if. (that's assuming we implement this for 6.14, it hasn't been done yet) Cheers, Simon
Hello Iain, Friday, January 29, 2010, 2:38:27 AM, you wrote:
I'm looking for a way of specifying language extensions in a way which will work in all versions of GHC from 6.4 onwards.
you can use compiler options or preprocess source before feeding it to ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 29 Jan 2010 at 13:50, Bulat Ziganshin wrote:
you can use compiler options or preprocess source before feeding it to ghc
Separate preprocessing: If there were a preprocessor which was readily available in a typical Haskell installation and could be simply persuaded to do the job (e.g. as a -F "Haskell" preprocessor), that might fit my requirements. I can't think of anything off-hand, but thanks for the suggestion. Compiler options: I want to use Cabal, so this would mean feeding the same options to all the source files, which isn't ideal. On the other hand, this would only apply to the earlier releases, perhaps only 6.4, and the detailed breakdown would be there in the LANGUAGE pragma for later releases, so this might actually be the most practical solution. -- Iain Alexander ia@stryx.demon.co.uk
Any sort of preprocessing at the beginning of a file appears to insert enough noise to inhibit recognition of file-header pragmas. (Cpphs doesn't appear to help here.)
The flag -P for traditional gnu cpp (or --noline for stand-alone cpphs) should suppress the initial #line noise. Does ghc still fail to recognise a module-start pragma, even if the only characters preceding it are whitespace? Regards, Malcolm
The flag -P for traditional gnu cpp (or --noline for stand-alone cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the only characters preceding it are whitespace?
I intended to give an example. ---- file foo.h ---- #if __GLASGOW_HASKELL__ == 604 #define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-} #else #define PRAGMA(foo) {-# LANGUAGE foo #-} ---- file Bar.hs ---- #include "foo.h" PRAGMA(MyLanguageOption) module Bar where ---- result ---- $ ghc-6.8.2 -E -cpp -optP-P Bar.hs $ cat Bar.hspp {-# LINE 1 "Bar.hs" #-} {-# LANGUAGE MyLanguageOption #-} module Bar where $ ghc-6.4.1 -E -cpp -optP-P Bar.hs $ cat Bar.hspp {-# OPTIONS_GHC -X MyLanguageOption #-} module Bar where
On 29 Jan 2010 at 15:14, Malcolm Wallace
The flag -P for traditional gnu cpp (or --noline for stand-alone cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the only characters preceding it are whitespace?
I'm not sure, but ghci apparently fails to recognise a file-header pragma if it is preceded by a {-# LINE ... #-} pragma.
I intended to give an example.
---- file foo.h ---- #if __GLASGOW_HASKELL__ == 604 #define PRAGMA(foo) {-# OPTIONS_GHC -X foo #-} #else #define PRAGMA(foo) {-# LANGUAGE foo #-}
---- file Bar.hs ---- #include "foo.h" PRAGMA(MyLanguageOption) module Bar where
---- result ---- $ ghc-6.8.2 -E -cpp -optP-P Bar.hs $ cat Bar.hspp {-# LINE 1 "Bar.hs" #-}
How on earth does the *C* preprocessor manage to insert a *Haskell* {-# LINE ... #-} pragma? (I see that myself as well in some configurations, some cpphs (which I could understand), but some not.)
{-# LANGUAGE MyLanguageOption #-} module Bar where
$ ghc-6.4.1 -E -cpp -optP-P Bar.hs $ cat Bar.hspp
{-# OPTIONS_GHC -X MyLanguageOption #-} module Bar where
-- Iain Alexander ia@stryx.demon.co.uk
participants (5)
-
Bulat Ziganshin -
Don Stewart -
Iain Alexander -
Malcolm Wallace -
Simon Marlow