Here's an idea I'd like to air: A new extension called AlternativePrelude. Like the NoImplicitPrelude extension we have already, this would disable implicitly importing the Prelude in every other module, but would also implicitly import a substitute. The purpose is to make it easier to play around with alternative preludes. Today we have to specify NoImplicitPrelude, but also explicitly import our alternative everywhere, making the transition between the different preludes that much more painful. With this new extension, the alternative prelude can be specified in the cabal file, or on the command line when building. This will hopefully make the alternative prelude efforts a little bit more mainstream, giving us more data we can use to consider modifications to the current standard prelude. I'm thinking the syntax would be something like AlternativePrelude="MyPrelude". This is new among the extensions in that it requires a parameter. An alternative is an ImplicitImport extension that doesn't disable the implicit importing of the Prelude, but while this does serve the same purpose as the AlternativePrelude proposal, I think it might be easier to use it for nefarious purposes. -- Sjur Gjøstein Karevoll
I'm thinking the syntax would be something like AlternativePrelude="MyPrelude".
There is a general principle that the semantics of a program should be completely described by the source code itself, and not dependent on options that may or may not be specified elsewhere. Hence, the idea of adding {-# LANGUAGE #-} pragmas, so that the source code is self- contained. Specifying {-# LANGUAGE NoImplicitPrelude #-} together with "import MyPrelude" satisfies this principle, as does {-# LANGUAGE AlternativePrelude="MyPrelude" #-} in all files where it matters. But the difference in usability is slight. If you are suggesting that {-# LANGUAGE AlternativePrelude="MyPrelude" #-} should somehow escape the scope of the module it appears in, then I think we heading for less firm ground. Regards, Malcolm
Laurdag 16. januar 2010 22.40.17 skreiv Malcolm Wallace:
I'm thinking the syntax would be something like AlternativePrelude="MyPrelude".
There is a general principle that the semantics of a program should be completely described by the source code itself, and not dependent on options that may or may not be specified elsewhere. Hence, the idea of adding {-# LANGUAGE #-} pragmas, so that the source code is self- contained.
Specifying {-# LANGUAGE NoImplicitPrelude #-} together with "import MyPrelude" satisfies this principle, as does {-# LANGUAGE AlternativePrelude="MyPrelude" #-} in all files where it matters. But the difference in usability is slight.
If you are suggesting that {-# LANGUAGE AlternativePrelude="MyPrelude" #-} should somehow escape the scope of the module it appears in, then I think we heading for less firm ground.
Regards, Malcolm
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Having a LANGUAGE pragma, or indeed any pragma, escape the module it's used in would be pretty silly, wouldn't it? In principle I'm a fan of the LANGUAGE pragmas. Self-contained source is usually much easier to read that source that depends on whatever command the author used to build the thing. However, the option to set language extension globally is still available, either as an option to the compiler when building, or in the cabal file describing the package. Allowing an alternative prelude in this fashion makes it easier to switch out the standard for alternatives in existing projects just to see what might happen, how things are changed or just for giggles. It might not be advisable to do so in code you plan on unleashing on the world, but it would make experimenting with alternatives cheaper than it currently is. -- Sjur Gjøstein Karevoll
On Sun, 2010-01-17 at 00:09 +0100, Sjur Gjøstein Karevoll wrote:
However, the option to set language extension globally is still available, either as an option to the compiler when building, or in the cabal file describing the package.
Hmm. Since the extensions should be specified in Cabal anyway (at least I guess it does some detection if compiler supports them) shouldn't it be specified in one place? Regards
Maciej Piechotka
However, the option to set language extension globally is still available, either as an option to the compiler when building, or in the cabal file describing the package.
Hmm. Since the extensions should be specified in Cabal anyway (at least I guess it does some detection if compiler supports them) shouldn't it be specified in one place?
I think there might be justification for doing it multiple places. The cabal file tells you what is required to build the package, the pragmas what is required to build each source file. Perhaps cabal should complain when source files use pragmas not declared in the cabal file, and perhaps also warn about options in the cabal file not used in any source file. -k (who didn't check the current state of affairs) -- If I haven't seen further, it is by standing in the footprints of giants
On Sun, Jan 17, 2010 at 12:27 PM, Ketil Malde
I think there might be justification for doing it multiple places. The cabal file tells you what is required to build the package, the pragmas what is required to build each source file.
Perhaps cabal should complain when source files use pragmas not declared in the cabal file, and perhaps also warn about options in the cabal file not used in any source file.
The "extensions" field in a cabal package description is a bit tricky. The documentation states "A list of Haskell extensions used by every module". This might give the impression that it documents the various extensions used in a package. What it actually does is enable those extensions for every module. Duncan's comments on this ticket are enlightening: http://hackage.haskell.org/trac/hackage/ticket/370 I think the idea of adding a new field "used-extensions" warrants a separate ticket.
Excerpts from Roel van Dijk's message of Sun Jan 17 13:50:22 +0200 2010:
The "extensions" field in a cabal package description is a bit tricky. The documentation states "A list of Haskell extensions used by every module". This might give the impression that it documents the various extensions used in a package. What it actually does is enable those extensions for every module.
Duncan's comments on this ticket are enlightening: http://hackage.haskell.org/trac/hackage/ticket/370
I think the idea of adding a new field "used-extensions" warrants a separate ticket.
Why not have Cabal autogenerate that information? Hackage already displays generated info like "Built on" and thus it should be doable. i.e. 1) Scan all the source files used for extension pragmas 2) Generate a list of those 3) Include that on Hackage The functionality needed for this is also needed for validating the proposed used-extensions field is correct, and thus not harder to implement. - Taru Karttunen
participants (6)
-
Ketil Malde -
Maciej Piechotka -
Malcolm Wallace -
Roel van Dijk -
Sjur Gjøstein Karevoll -
Taru Karttunen