Hi Cabalites, I fear this may be contentious, but here goes anyway... Currently we have (at least) 4 ways that extension E can be enabled for a given file in a cabal package (using GHC as an example, if -fe enables E): 1. foo.cabal: Extensions: E 2. foo.cabal: Ghc-Options: -fe 3. Foo.hs: {-# LANGUAGE E #-} 4. Foo.hs: {-# OPTIONS_GHC -fe #-} Ideally, from cabal's point of view, we would use option 1. This way cabal knows about the extensions, so can fail early if we don't support the necessary extensions to build something. 2 and 4 are inferior variants of 1 and 3 respectively; the only case I can think of where you might want to use them is if cabal doesn't know about the extension yet. This could be solved by a --language=E flag that GHC treats identically to -fe. Obviously cabal can't check that GHC supports this extension in advance (so would have to assume that it does), but at least we no longer have any need to enable extensions with method 2 or 4. We could also then have Cabal always pass a --no-extension-flags flag, which would mean that GHC would reject -fe. That wasn't the contentious bit, so hopefully you aren't too inflamed yet! Suppose we agree that we should only use method 1; there are a number of issues: * If someone uses method 3, no alarm bells will sound. The package will continue to build where it can be built. * The same set of extensions is used for every module. For example, if you want to allow overlapping instances in one particular place[1] then you must allow them everywhere. * If you want to load one of the modules in ghci, say, then you need to tell it what flags to use. Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted. Any comments? Criticisms? Flames? Thanks Ian [1] Currently we can only specify this to a file-level granularity, but in principle you could imagine more localised pragmas, like we have for unboxed fields.
Hi
Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
I like it!
* If you want to load one of the modules in ghci, say, then you need to tell it what flags to use.
I think this is the killer reason. Another reason that you don't mention is that it discourages the use of extensions, not massively, but slightly. Now if you want to use a particular extension lots you must specify it in every single file. Thanks Neil
On Fri, 2007-03-23 at 21:42 +0000, Neil Mitchell wrote:
Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
I like it!
So do I.
* If you want to load one of the modules in ghci, say, then you need to tell it what flags to use.
I think this is the killer reason.
That would be helpful. See also Alexander Jacobson's recent email on this topic: http://www.haskell.org/pipermail/haskell/2007-March/019265.html
Another reason that you don't mention is that it discourages the use of extensions, not massively, but slightly. Now if you want to use a particular extension lots you must specify it in every single file.
Obviously it'd be easier on users / developers if Cabal could tell you if you need to add extra allowed extensions that you're using. For that we need to scan the .hs files, which probably means we need the full dep analysis too. Duncan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Lynagh wrote:
* The same set of extensions is used for every module. For example, if you want to allow overlapping instances in one particular place[1] then you must allow them everywhere.
You explicitly have to add potentially dangerous extensions when you need them, that would be a gain, the downside being that you actually have to write them...
* If you want to load one of the modules in ghci, say, then you need to tell it what flags to use.
It's more or less this that raised this question at all. Big gain if you didn't have to.
Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
Yes! It's a compiler independent way of adding extensions, yet the control of what can be used is maintained by Cabal. There will be a phase when many cabal projects has to be adapted, but it might just be worth it. I like it a lot, thanks Ian! Cheers, Lennart Kolmodin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGBROJ4txYG4KUCuERAhgSAKC0vYn1QnbvlxGu7raliWCXup2y9QCdEZTv 8lubE63mxDkZ2Guwyg8Vlrk= =hTWC -----END PGP SIGNATURE-----
Ian Lynagh
Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
The only thing I can think of (besides "nice idea") is that you'd better either a) make sure that Cabal always knows about all the extensions supported by the compiler or b) provide a workaround for when Cabal does not know about a given extension.
On Sat, Mar 24, 2007 at 10:53:54PM +0000, Samuel Bronson wrote:
Ian Lynagh
writes: Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
The only thing I can think of (besides "nice idea") is that you'd better either a) make sure that Cabal always knows about all the extensions supported by the compiler or b) provide a workaround for when Cabal does not know about a given extension.
We already have this, it's called darcs send. That said, cabal is very sorely lacking hacker's documentation. I for one can't understand the code. (yet (but still I learned lambdabot faster)) Stefan
On Sat, Mar 24, 2007 at 10:53:54PM +0000, Samuel Bronson wrote:
Ian Lynagh
writes: Thus I propose that the .cabal file actually specifies what extensions the modules are /allowed/ to use, but does not actually enable them. They would then be enabled by LANGUAGE pragmas in the modules as necessary. So, if the .cabal file says "Extensions: E, F" then the modules will be compiled with --no-extension-flags --allowed-extension=E,F and if a module has "{-# LANGUAGE E #-}" then only extension E would be enabled for that module. If a module has "{-# LANGUAGE E,G #-}" then compilation would fail as extension G is not permitted.
Any comments? Criticisms? Flames?
The only thing I can think of (besides "nice idea") is that you'd better either a) make sure that Cabal always knows about all the extensions supported by the compiler or b) provide a workaround for when Cabal does not know about a given extension.
That's the --language=E flag in the paragraph beginning "2 and 4". But actually, Cabal would no longer enable extensions with this flag anyway, it would just list the extensions after the --allowed-extension flag (and it doesn't need to recognise them to list them). Thanks Ian
participants (6)
-
Duncan Coutts -
Ian Lynagh -
Lennart Kolmodin -
Neil Mitchell -
Samuel Bronson -
Stefan O'Rear