[Haskell-cafe] Hackage being too strict?

[John Meacham]

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⑈