consistency in "ghc-pkg field '*' haddock-html"?

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sat Jul 19 21:25:51 EDT 2008


On Sat, 2008-07-19 at 21:58 +0100, Claus Reinke wrote:
> >> - some entries '/', some use '\\', some use a combination of
> >>     '/' and *unescaped* '\' (the latter two come from ghc's
> >>     cabal configure run either with or without --prefix)
> > 
> > That's fine. They use \\ when using Haskell String format. When not then
> > windows accepts both \ and / as path separators, it's not an escape
> > char.
> 
> Since windows is so forgiving, why not be consistent and always
> use '/'?

We do. But if someone passes Cabal a path containing '\' then we don't
interpret or check it, we just use it.

> That also reduces the number of escapes as well as the 
> danger of missing escapes when going via several levels of 
> shells/interpretation. Only the double quotes to protect spaces
> remain necessary.

The convention everywhere in Cabal (and in the ghc-pkg registration
files) is to allow Haskell String syntax. It's only essential when one
wants to use characters that would otherwise be interpreted as
separators.
 
> > It's not strictly necessary for ghc-pkg to know where index files are
> > that cover various packages but it would be nice to do something better
> > there. People ask for Cabal to maintain an index over all packages
> > though it's not clear where it should put this.
> 
> For context: I've just extended the haskellmode plugins for Vim
> to handle docs for libraries outside code+extra (not yet online), 
> and while it was no big deal working around all those inconsistencies, 
> it certainly seemed unnecessary and ugly.  
> 
> Right now, only core+extralibs have a unified index, and that can
> be found by all kinds of ugly guesses (though ghc-paths will help
> there in the future). Once Cabal generates and maintains a master
> index, perhaps there could simply be a standard file pointing to it,
> in the haddock-html dirs?

It would not be per-package of course so I don't think it makes sense to
put it in package registration files.

Duncan



More information about the cabal-devel mailing list