-1 for me. In case that was unclear.
On 25 April 2014 14:57, Alain O'Dea <alain.o...@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 <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 >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users