RE: state of the cabal (preprocessors)
On 20 October 2004 15:07, Henrik Nilsson wrote:
[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.
But what about interpreters? Would it be the build-system's responsibility (be it Cabal's simple build system or a make based system called from Cabal or whatever) to look for options pragmas in the source and run CPP if neccessary on those files?
Yes, but that's pretty easy. Slightly more difficult that just inspecting the extension, but still easy. GHC's version of the code is here: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/~checkout~/fptools/ghc/compile r/main/DriverUtil.hs?rev=1.45;content-type=text%2Fplain (getOptionsFromSource function).
If so, at least for make-based systems, a scheme based on file extensions is probably easier to handle?
If not, then it would seem that non-preprocessed sources do get installed, and that Hugs would have to look for the option pragma on a per file bases and run CPP if necessary before loading the source? Perfectly OK, except that I still think it is a good idea to preprocess only once.
For make-based systems, you're probably using a compiler in which case you just delegate CPP to the compiler. The tricky cases are - make-based build system for Hugs. (pretty rare, I'd guess) - CPP'ing source for feeding to Haddock For both of these cases, the make-based build system could just defer to Cabal once it has done whatever setup is required.
Finally, does not the option pragma solution imply that CPP-ing always is the last preprocessing step?
This might be a reasonable assumption, but at least Malcolm raised concerns about building such an assumption into the tools.
When it is Haskell preprocessing, yes. Preprocessing Happy (or other) sources with CPP is still possible using the .cpp extension convention - I'm only proposing we drop the .cpp when it follows .hs or .lhs. Cheers, Simon
"Simon Marlow"
[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.
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. Regards, Malcolm
"Simon Marlow"
[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@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.
Henrik Nilsson writes:
{-# OPTIONS ... #-}
I also think that this is the best way of specifying flags you know the module will need (like -fffi or -cpp), simply because it's the only way to specify these options if you want to build the program with --make and cannot pass all those options to all modules globally. Peter
Henrik Nilsson
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
I think Simon was suggesting the pragma {-# LANGUAGE ... #-} for a compiler-independent specification of the specific language extensions required by a module - this could indeed be in a format derived from Cabal. However, in the meantime, {-# OPTIONS[-xHC] ... #-} already exists, and is a less-rigorous means to the same end, since it often uses stuff like "-cpp", "-ffi", "-puns", whatever, but compiler-specific.
* reduce the needs for #ifdefs.
I don't see how the use of pragmas will directly reduce the need for conditional imports. Eventually, the libraries shipped with compilers will converge sufficiently to reduce differences in imports, but that is a separate issue.
{-# OPTIONS_COMPILE ... #-} {-# OPTIONS_LINK ... #-}
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?
I was thinking for instance of an FFI binding to an external library. E.g. {-# OPTIONS_COMPILE `glib-config --cflags` #-} {-# OPTIONS_LINK `glib-config --libs` #-} module Glib where ... The idea was to help 'hmake'. Only the binding module needs to know about what extra linking options (e.g. -lglib -L/pkg/glib) are required, yet when a program that /uses/ the module is built, we must still discover these extra dependencies. However, I am willing to be convinced that this extra mechanism is unnecessary, especially in view of the more recent emergence of the 'package' mechanism, which can neatly encapsulate exactly this kind of detail. Regards, Malcolm
Malcolm Wallace wrote:
I think Simon was suggesting the pragma {-# LANGUAGE ... #-} for a compiler-independent specification of the specific language extensions required by a module - this could indeed be in a format derived from Cabal.
Very good.
I don't see how the use of pragmas will directly reduce the need for conditional imports. Eventually, the libraries shipped with compilers will converge sufficiently to reduce differences in imports, but that is a separate issue.
I simply meant that it would be unfortunate if one had to resort to CPP just because of some incompatibility between the command-line syntax of the various compilers. E.g., I'd rather not write things like #ifdef __GHC__ {-# OPTIONS ... #-} #endif #ifdef __NHC__ {-# OPTIONS ... #-} #endif /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.
participants (4)
-
Henrik Nilsson -
Malcolm Wallace -
Peter Simons -
Simon Marlow