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

[Claus Reinke]

>> 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. And even that could be cured by having
the collection of rules updateable, separately from Cabal itself. 

And when the forthcoming next base split, and extensible exceptions, 
and Cabal Api changes, and .. are going to introduce new break points,
updating the rules will offer help for those breakages, too.

Given the shakiness of this simplistic approach, one might not want 
to enable it by default, but what about an option '--explain' and a
hint if things go wrong: "if you would like help interpreting common
Cabal package issues, you can try repeating your command with 
our experimental --explain option".

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.

> If one wanted to take this approach you'd need to have some mode where
> error messages are produced in a machine readable format (which is of
> course doable if you write a client using the ghc api).
> 
> A quicker hack would be to change ghcs error message in this
> circumstance, where the -hide-all-packages flag is given.

One would want to have such support depend on an extra option,
'--errors-in-xml' or something equally scary, but I'm afraid the extra
readability/stability would be mostly illusionary. We're talking about
"good enough" hacks to cover "not quite right" left-overs from too
much instability in the Haskell tool chains - as long as the instabilities
remain, there is no "perfect" solution.
 
> Given our limited amount of volunteer developer time I think it's 
> much better investing it in proper solutions.

How many times over the last 9 months have you had to explain 
what a script could have told your Cabal users? And how many 
more Cabal/Haskell users have been scared away in that time, 
without even raising their build problems on any of the lists?

"Proper" solutions are alright when we have them. "Good enough"
but hacky is much better than nothing. With an '--explain' option
and a collection of rules, you'd have to explain every error condition
just once, then update the rules/explanations, and let Cabal repeat
the explanation whenever needed. If those canned explanations 
don't work, users can still ask here.

Claus