RFC: changes to -i flag for finding source files

[Alain O'Dea]

-1 for me. In case that was unclear.


On 25 April 2014 14:57, Alain O'Dea <alain.odea at gmail.com> wrote:

> I have trouble with this as it breaks expectations around directory
> structure mirroring the module hierarchy.
>
> I would be very confused reading the source code of a project that availed
> of this feature as it would break my expectations of how to navigate to
> source files based on their module hierarchy.
>
> I'm not sure how the tool support is implemented in Vim, Emacs, Yi, Leksah
> etc., but changing this may break the tool's ability to provide jump to
> symbol.
>
> I imagine other unforeseen challenges with source dependency analysis
> elsewhere in the GHC toolchain may also arise if they assume that the
> directory layout reflects the module hierarchy.  The Java toolchain
> certainly falls over when the corresponding package-flattening trick is
> performed on a Java codebase.  The workarounds are viral and wind up
> complicating builds considerably.
>
> I could also be totally out to lunch here.
>
> > On Apr 25, 2014, at 13:17, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140425/805a1b19/attachment-0001.html>