state of the cabal (preprocessors)
Henrik Nilsson
nhn at Cs.Nott.AC.UK
Mon Oct 25 10:55:05 EDT 2004
"Simon Marlow" <simonmar at microsoft.com> writes:
> > [Aside: Is there a general agreement that the OPTION pragma should
> > be understood by all Haskell systems, whereas system-specific
> > options are given by pragmas like OPTIONS-GHC, OPTIONS-NHC, etc.
> > or something along those lines?]
>
> I'm happy to switch to using {-# OPTIONS_GHC #-} (or something) if
> there's consensus. Consider that a vote in favour on behalf of the
> GHC camp.
Just to clarify.
I believe a scheme like this would make it simpler to write code
that works across different Haskell system even in cases where it is
necessary to give special instructions to the compiler on a per-file
basis. Specifically, such a scheme would
* encourage the standardization of the syntax and semantics for
"important" command-line options
* reduce the needs for #ifdefs.
The latter would be particularly important if the consensus is that the
way to enable CPP-ing of source files on a per-file basis is through
the OPTION pragma mechanisms, rather than through agreed filename
extensions.
For the scheme to work, the various implementors would have to agree
on the syntax and semantics of the OPTION options, and agree to either
implement the feature in question, or else behave "sensibly" if the
option is encountered (e.g. by ignoring it or aborting and emitting an
error message).
[Aside: Might it be a good idea to allow Cabal-style language extension
specifiers to be listed in an EXTENSION pragma? Enabling extensions
locally would seem useful at last for some extensions, and in general
being able to state what language a module actually is written in
has its attractions. Of course, this could be done via the OPTION
pragma mechanism, but since Cabal already has a more principled and
abstract way of specifying extensions, maybe it would make sense to
allow that mechanism to be used for individual files?]
Malcolm Wallace writes:
> Currently I believe ghc uses
> {-# OPTIONS ... #-}
> whilst nhc98 uses the pair
> {-# OPTIONS_COMPILE ... #-}
> {-# OPTIONS_LINK ... #-}
> and Hugs has
> #!runhugs ...
>
> I have no specific preferences for naming, and am happy to change to
> whatever consensus arrives. However I do think separating out extra
> link options from the compile-time options could be useful.
Could you elaborate on this, please? E.g. through some examples.
What kind of link options do you have in mind? Are they independent
of the Haskell system and operating system, or might they depend
on either or both?
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.
More information about the Libraries
mailing list