JHC has the feature that

Graphics.UI.GTK.Button can live in any of:

Graphics/UI/GTK/Button.hs
Graphics/UI/GTK.Button.hs
Graphics/UI.GTK.Button.hs
Graphics.UI.GTK.Button.hs

It lets you have deep module hiarchies without deep directory
hierarchies and is not terribly surprising as behaviors go.

     John

On Fri, Apr 25, 2014 at 6:17 AM, Simon Marlow <marlo...@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@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
John Meacham - http://notanumber.net/
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to