state of the cabal (preprocessors)

[Henrik Nilsson]

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