RFC: changes to -i flag for finding source files

Eric Seidel gridaphobe at gmail.com
Fri Apr 25 14:16:03 UTC 2014

An alternative (and I think this has also been proposed before) is to
simply drop the Graphics.UI header from the module hierarchy. The main con
here is that there's an increased risk of module name-clashes, but GHC
already solves this with the PackageImports extension.

On Friday, April 25, 2014, Simon Marlow <marlowsd at gmail.com> wrote:

> I want to propose a simple change to the -i flag for finding source files.
>  The problem we often have is that when you're writing code for a library
> that lives deep in the module hierarchy, you end up needing a deep
> directory structure, e.g.
>  src/
>    Graphics/
>      UI/
>       Gtk/
>         Button.hs
>         Label.hs
>         ...
> where the top few layers are all empty.  There have been proposals of
> elaborate solutions for this in the past (module grafting etc.), but I want
> to propose something really simple that would avoid this problem with
> minimal additional complexity:
>   ghc -iGraphics.UI.Gtk=src
> the meaning of this flag is that when searching for modules, ghc will look
> for the module Graphics.UI.Gtk.Button in src/Button.hs, rather than
> src/Graphics/UI/Gtk/Button.hs.  The source file itself is unchanged: it
> still begins with "module Graphics.UI.Gtk.Button ...".
> The implementation is only a few lines in the Finder (and probably rather
> more in the manual and testsuite), but I wanted to get a sense of whether
> people thought this would be a good idea, or if there's a better
> alternative before I push it.
> Pros:
>   - simple implementation (but Cabal needs mods, see below)
>   - solves the deep directory problem
> Cons:
>   - It makes the rules about finding files a bit more complicated.
>     People need to find source files too, not just compilers.
>   - packages that want to be compatible with older compilers can't
>     use it yet.
>   - you can't use '=' in a source directory name (but we could pick
>     a different syntax if necessary)
>   - It won't work for Cabal packages until Cabal is modified to
>     support it (PreProcess and SrcDist and perhaps Haddock are the only
>     places affected, I think)
>   - Hackage will need to reject packages that use this feature without
>     also specifying ghc >= 7.10 and some cabal-version too.
>   - Are there other tools/libraries that will need changes? Leksah?
> Cheers,
> Simon
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140425/2901586a/attachment.html>

More information about the Glasgow-haskell-users mailing list