[Haskell-cafe] Hackage being too strict?

[Duncan Coutts]

In message <20080418121351.GJ17560 at sliver.repetae.net> haskell-cafe at haskell.org
writes:
> 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?

No, that's the nice thing about the changes I've made already. It already works
(in Cabal-1.4) to use the PArr extension that ghc-6.8.2 supports but is not
finalised yet and is therefore not listed in Language.Haskell.Extension.

So only the list that the hackage server itself knows about has to be updated so
that it can 

> It should just be 
> 
> > newtype Extension = Extension String

Perhaps but the main point I think this that Cabal/Hackage needs to know both
what the global list of known extensions and what extensions are supported by
particular versions of compilers.

It's obviously legitimate for compilers to add new extensions that are not
globally registered (and that works now in Cabal-1.4) but I don't think it's
legitimate to have such packages be uploaded to hackage. If they're going to be
publicly distributed then the extensions they use should be known too.

Then there's the simple matter of reporting to users that they've mis-spelled an
extension. We need enough information about known extensions to be able to do that.

> 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.

Yeah maybe. I don't really care about the representation so long as we can all
agree about what users/packagers/hackage/compilers want from extensions.

Duncan