On Fri April 18 2008 4:43:24 am Duncan Coutts wrote:
It seems arbitrary that Hackage would suddenly reject this valid usage.
Yes it is valid though I hope you can see the general intention of the suggestion. If it were not for the compatibility problem it would be preferable to use:
Sure, I do. It's a good point. But I think there are a couple of issues here: 1) Hackage is rejecting things that Cabal accepts without trouble 2) The behavior of Hackage is unpredictable in what it will accept and what it will reject 3) The behavior of Hackage changes rapidly It's been quite frustrating lately as many of my packages that used to upload fine still build fine but get rejected at upload time. I think that Hackage is the wrong place for these checks. This stuff should go in Cabal, and ./setup configure should print a big DEPRECATION WARNING for a major release before the stuff gets yanked.
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,
That's great news.
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.
That makes sense.
So that obviously does not solve the problem that Cabal-1.2 and older are not very good with forwards compat in the parser. The solution is probably just to downgrade that check to a warning rather than outright rejection (or possibly limit the check to extensions that existed in older Cabal versions). We can make it stricter again in the future when Cabal-1.4+ is much more widely deployed.
Sound ok?
Yes, that makes a lot of sense, too. Can cabal-put be tweaked to make sure to output that warning by default? -- John