Cabal feedback notes

[Krasimir Angelov]

--- Simon Marlow <simonmar at microsoft.com> wrote:
> localPackageConfig is only for GHC 6.2: in 6.4, GHC
> and ghc-pkg will
> know where the local package conf lives, so Cabal
> won't need this
> knowledge built-in.

Good!

> Last time this came up I asked for a concrete
> proposal, but no-one came
> forward with one.  I'd do it myself, but I'm kind of
> busy right now.
> Would someone care to whip up a list of functions &
> signatures?

Ok. I will look at Python's OS.Path module, .Net's
System.IO.Path class and the Utils module from Cabal
and will summarize an API proposal together with some
implementation.

> I'm inclined to just stick something into the
> libraries even if it's not
> perfect.  The filename handling issue is one of
> those things where
> trying to define a perfectly portable library is
> hard if not impossible,
> but having *something* is going to be useful to a
> lot of people, and as
> Krasimir says it'll have a lot of duplicated code.
> 
> Data.FilePath or System.Directory?  I'm inclined
> towards the latter,
> since we clearly want functions that actually
> inspect the filesystem
> (findBinary, getExecutableFilePath) along with
> functions that just
> manipulate filenames, and it seems strange to split
> them up.

I prefer System.FilePath and System.Directory.
Data.FilePath was my previous propsal but System is
more suitable. In both Python and .Net there are
separated namespaces for functions which are doing
real IO operations and for FilePath parsing routines.

Cheers,
  Krasimir




		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com