[Haskell-cafe] Re: problem with cabal for syb-with-class

[Duncan Coutts]

On Wed, 2008-08-27 at 12:33 +0100, Claus Reinke wrote:
> >> Cabal doesn't have to pass on ghc's messages uninterpreted. That's
> >> a lot like implementing a map as a list and complaining about empty
> >> list instead of element not found.
> > 
> > I see what you're saying, but in practise it's just not possible. GHC
> > can return a non-zero exit code for a multitude of reasons (most of
> > which will be genuine errors in your source code). It's just not
> > practical to parse the error messages that ghc produces and try and
> > reinterpret them. I fear it'd quite easy to introduce more problems than
> > are solved this way.
> 
> Introducing more problems is quite possible, though changes in error
> messages should mostly mean that the rules won't trigger and no
> helpful explanation is given.

Yes, it if it can degrade gracefully that's not so bad.

> And even that could be cured by having the collection of rules
> updateable, separately from Cabal itself. 

Hmm. Yet more work.

> What I don't understand are your "in practise it's just not possible"
> and "It's just not practical to parse the error messages that ghc produces 
> and try and reinterpret them". I assume you've tried the code I first
> sent some 9 months ago, and again this week, and found that it wouldn't 
> work for some reasons,but you haven't told me those reasons yet.

The easiest reason is that we cannot use regexes in Cabal, but that's
really just skirting the issue. The next reason is that it is still a
not insignificant effort to integrate this concept. The honest reason is
that I don't like the whole approach and I'm not inclined to spend my
time on it.

I'm not saying I'd reject a working patch against Cabal HEAD, just that
I'm not interested it doing it myself. Feel free to file a ticket,
attach your proof of concept code and persuade someone to put in the
time. If it works and doesn't look like it'd cause more problems than it
solves then I'd be happy to apply such a patch.

Duncan