On Fri, Apr 18, 2008 at 10:43:24AM +0100, Duncan Coutts wrote:
I have now fixed that by eliminating the use of Read in the .cabal parser and basically adding an Other/Unknown constructor to several of the enumeration types, including Extension. So as of Cabal-1.4 it will be possible to add new extensions in later Cabal versions that are not in Cabal-1.4 without Cabal-1.4 falling over with a parse error. Indeed, if the compiler knows about the extension then it will actually work. The only restriction is that unknown extensions cannot be used in packages uploaded to hackage, which is pretty reasonable I think. If an extension is going to be used in widely distributed packages then that extension should be registered in Language.Haskell.Extension. It's trivial to add and update hackage to recognise it.
And then have everyone have to upgrade their cabal? It should just be
newtype Extension = Extension String
it would simplify a lot of code, be more forwards and backwards proof, and remove oddness like do 'Other "PatternGuards"' and 'PatternGuards' mean the same thing? In order to be both backwards and forwards compatable, everyone writing haskell code that links against cabal and cares about extensions will have to have special code treating both the same, and in fact, conditionally compile part of it, since 'PatternGuards' might not even be valid in some old version of cabal. (replace PatternGuards with some other soon to be standardized extension) Normalized data types are a good thing. A centralized registry of things hackage recognizes is fine, but it shouldn't be cluttering up the source code. John -- John Meacham - ⑆repetae.net⑆john⑈