On Monday 02 April 2007 10:28, Simon Peyton-Jones wrote:
> | > * jiggle with cpp magic
> | > The use of cpp macros _as well as_ conditionals to define which
> | > modules to import is horrible. More to the point, it breaks hmake,
> | > which (for good reason) only supports conditionals not macros. Since
> | > the conditional-only mechanism is equal in power, there's no reason
> | > to use the more general macro facility.
> | >
> | > M ./System/FilePath.hs -4 +4
> |
> | The current state of things is not much better: Due to the CPP trickery,
> | the GHC build system misses dependecies on the internal module. I can
> | understand the motivation behind all this preprocessing magic, but we
> | have to solve this differently somehow...
>
> We're all ears!
I am still not 100% sure if I understand all use cases. There are 3 visible
modules (although only 2 show up in Haddock):
* One for POSIX-like file paths
* One for Windows-like file paths
* One for the "native" file paths on the current platform (a re-export of
one of those two above)
Is it really a hard requirement to e.g. be able to handle Windows paths on a
Linux machine? I.e. do we really need to expose all three modules to the user
or is a single ("native") one sufficient? I thought that this package should
hide the differences.
Cheers,
S.
_______________________________________________
Cvs-libraries mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-libraries
