Language extensions - backwards compatibility

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Language extensions - backwards compatibility

Iain Alexander
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      [hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Don Stewart-2
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?
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Simon Marlow-7
In reply to this post by Iain Alexander
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Bulat Ziganshin-2
In reply to this post by Iain Alexander
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:[hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Malcolm Wallace
In reply to this post by Iain Alexander
> 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




_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

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 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





_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Iain Alexander
In reply to this post by Don Stewart-2
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      [hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Iain Alexander
In reply to this post by Bulat Ziganshin-2
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      [hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Language extensions - backwards compatibility

Iain Alexander
In reply to this post by Malcolm Wallace
On 29 Jan 2010 at 15:14, Malcolm Wallace <[hidden email]> wrote:

> > 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      [hidden email]

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users