Hi all,

To hopefully wind up this discussion, I'd like to make three proposals:

Basically looks good to me.

1. That if a compiler understands an in-file pragma specifying options, it should take the form {-# OPTIONS_<compiler> ... #-}.

Of course, it is really up to each implementation to decide how to handle its own OPTIONS pragmas. But to avoid confusion, it would be helpful if the implementors could agree to process these pragmas in a reasonably similar way. The GHC approach seems good, which I understand as follows: * Options are collected from one or more OPTIONS pragmas in order * The in-file options are prepended to the command-line options. An additional issue is *where* OPTIONS pragmas get recognized. The current GHC approach is as follows: OPTIONS pragmas are only looked for at the top of your source file, up to the first (non-literate, non-empty) line not containing OPTIONS. In view of there now being OPTIONS pragmas for a number of different compilers this approach would have to be refined, or all but one system would not be able to find their options! Also, when/if the LANGUAGE pragma is added, it would be sensible if exactly the same rules applied to that. One could refine the above rule in such a way that it would work for all forms of OPTION/LANGUAGE pragmas and in such a way that that the interleaving with option pragmas for other compilers do not interfere. However, at least superficially, it would seem simpler (and more flexible, since normal comments would not interfere) to simply require that all OPTIONS/LANGUAGE pragmas must occur before the keyword "module". But maybe that is hard to implement, or undesirable for some other reason?

2. We introduce a new pragma to specify the language extensions in force for the current source file. I suggest: {-# LANGUAGE <ext1>,...,<extn> #-} where <ext> is taken from the list of extensions understood by Cabal in the 'extensions' field of a package description (eg. OverlappingInstances, RecursiveDo, etc.).

Yes, I like this. Do we have to worry about how LANGUAGE, OPTIONS_XXX and command line options (some of which may have originated from global Cabal language extension specifications, presumably) interact? I suspect *not*, since all language extension specifiers seem to turn ON the specified feature. If that is the case, simply taking the union of all specifiers (not worrying about order) should do?

3. We add CPP to the list of extensions in Cabal, so you can say {-# LANGUAGE CPP #-} to get C preprocessing in the current file, or add CPP to the list of extensions in the package description to get CPP on > every file. That doesn't preclude also using a .cpp extension, but it means you don't have to.

Sounds good.

Hmm, I've just realised some problems with this. Hugs probably won't be implementing {-# LANGUAGE #-} any time soon (I imagine?) so it wouldn't be portable. Also old compilers don't implement it, so we have a difficult migration path.

I assume that Hugs and old compilers just would ignore {-# LANGUAGE #-} since the Haskell report explicitly requires an implementation to ignore pragmas it does not understand. If so, the build-system could lend a helping hand to Hugs and other systems that do not understand LANGUAGE by looking for LANGUAGE pragmas on behalf of the compiler and invoke it with the appropriate flags. Not sure that would be much fun to implement in a make-based system, but I should think it would be fairly easy to implement in the context of Cabal's simple build system, in particular since there must be some mechanism to translate language extension specifications into compiler-specific options already. When it comes to the CPP "extension" (and Arrows, and maybe other preprocessors), it would seem as if the build system HAS to look for any LANGUAGE pragmas anyway when dealing with Hugs since there was consensus that preprocessing should happen only once, and preprocessed sources are what should get installed. As to backwards compatibility in general, would there be a problem if GHC and NHC continue to support their respective OPTIONS variants as a deprecated feature? Then no old code should break. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.