Re: RFC: changes to -i flag for finding source files
On 30/05/14 11:10, John Meacham wrote: On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak wrote: Well, it might not be terribly surprising in itself, but we just have quite complex systems and the not terribly surprising things just accumulate and then it might get surprising somewhere. I really prefer simplicity and explicitly. If a central tool like GHC adds this behaviour, then all other tools are forced to follow. Well, I just proposed it as an alternative to some of the other ideas floated here. A command line flag like -i would definitely be ghc specific and inherently non-portable. Just to clarify this point, what I proposed was not intended to be compiler-specific, because it would be a change to the hs-source-dirs field of a .cabal file, and implemented in whatever way each compiler wants to do it. In the case of GHC the hs-source-dirs are just wrapped in -i flags. Still, I'm not planning to push the change into GHC because (a) changes are needed in Cabal and a few other places, (b) opinion was divided, and (c) it's not a big enough win. JHC's semantics would also need changes in Cabal, incidentally, for the same reason: supporting 'sdist' (and possibly other reasons that I've forgotten). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-05-30 11:00, John Meacham wrote: > 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. > This sounds much more appealing idea in that all the necessary information is still in the file system and not tangled up in the build specification (compiler flags). Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
No, it would be trivial to make it do so, but it would be ususual and contrary to how ghc does things. For instance, ghc doesnt warn if both Foo.lhs and Foo.hs exist or src/Foo.hs and bar/Foo.hs when both -isrc and -ibar are specified on the command line. John On Fri, May 30, 2014 at 3:10 AM, Herbert Valerio Riedel wrote: > On 2014-05-30 at 11:00:38 +0200, John Meacham wrote: >> 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 > > Just wondering: Does JHC warn if, for instance, > `Graphics/UI/GTK/Button.hs` as well as `Graphics.UI.GTK.Button.hs` exists? -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak wrote: > Well, it might not be terribly surprising in itself, but we > just have quite complex systems and the not terribly surprising > things just accumulate and then it might get surprising somewhere. > > I really prefer simplicity and explicitly. > > If a central tool like GHC adds this behaviour, then all other > tools are forced to follow. Well, I just proposed it as an alternative to some of the other ideas floated here. A command line flag like -i would definitely be ghc specific and inherently non-portable. John -- John Meacham - http://notanumber.net/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-05-30 at 11:00:38 +0200, John Meacham wrote: > 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 Just wondering: Does JHC warn if, for instance, `Graphics/UI/GTK/Button.hs` as well as `Graphics.UI.GTK.Button.hs` exists? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On Fri, May 30, 2014 at 02:00:38AM -0700, John Meacham wrote: > 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. Well, it might not be terribly surprising in itself, but we just have quite complex systems and the not terribly surprising things just accumulate and then it might get surprising somewhere. I really prefer simplicity and explicitly. If a central tool like GHC adds this behaviour, then all other tools are forced to follow. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
I would personally love to see this feature ported to GHC. Best regards, Krzysztof On Fri, May 30, 2014 at 11:00 AM, John Meacham wrote: > 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 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 > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
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 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
Re: RFC: changes to -i flag for finding source files
> Thanks for all the feedback. Clearly opinion is divided on this one, > so I'll sit on it and think it through some more. My assumption was that with what Felipe Lessa suggested, this proposal is pretty much obsolete. As I understand it, it provides the same benefits, the major difference being that you create a symlink instead of specifying a command line flag. It has been pointed out that symlinks work just fine with git. I can see two advantages of this approach over the original proposal: - Cabal and other tools will continue to work without any modification - Somebody working with your code who is not aware of the "shortcut", will still find the source files where he expects them Are there any disadvantages? Cheers. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
2014-04-25 22:26 GMT+02:00 Malcolm Wallace : > [...] The feature seems like a very low power-to-weight ratio, so -1 from me. -1 from me, for the same reasons. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Coming from Scala where I can basically structure my directory sources the way I want I got a bit frustrated by Haskell rigidity here. So definitely a +1, and I agree cabal support is quite important. OTOH, I don't think Haskell should go in the way of allowing 'any' structure (like scala), but being able to have shortcut like that would be definitely beneficial. Also, I don't think integrating such feature will be an issue for the text editors "jump to declaration" feature, as they should usually use `tags` files. On 28 April 2014 09:40, Roman Cheplyaka wrote: > * Simon Marlow [2014-04-28 09:26:23+0100] > > On 25/04/2014 17:57, Roman Cheplyaka wrote: > > >* Edward Kmett [2014-04-25 11:22:46-0400] > > >>+1 from me. I have a lot of projects that suffer with 4 levels of > vacuous > > >>subdirectories just for this. > > >> > > >>In theory cabal could support this on older GHC versions by copying > all of the > > >>files to a working dir in dist with the expected layout on older GHCs. > > >> > > >>That would enable this to get much greater penetration more quickly. > > > > > >I'd really not want that people start putting ghc-options: -isrc=... > > >into their cabal files. That'd make them irrecoverably ghc-specific, as > no other > > >tool will know how to process the files unless it reads ghc-options. > > > > No, the idea would be to use hs-source-dirs like this: > > > > hs-source-dirs: A.B.C=src > > > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > > except that Cabal needs to preprocess some source files so it needs to > find > > them, and also sdist needs to find source files. > > In that case, I'm in favour of this proposal. > > Please consider the reversed syntax instead: > > hs-source-dirs: src=A.B.C > > I find it more intuitive, because A.B.C becomes sort of an optional > parameter, > the empty prefix being its default value. > > Roman > > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > -- *Alois Cochard* http://aloiscochard.blogspot.com http://twitter.com/aloiscochard http://github.com/aloiscochard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 28 April 2014 18:40, Roman Cheplyaka wrote: > * Simon Marlow [2014-04-28 09:26:23+0100] > > No, the idea would be to use hs-source-dirs like this: > > > > hs-source-dirs: A.B.C=src > > > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > > except that Cabal needs to preprocess some source files so it needs to > find > > them, and also sdist needs to find source files. > > In that case, I'm in favour of this proposal. > > Please consider the reversed syntax instead: > > hs-source-dirs: src=A.B.C > > I find it more intuitive, because A.B.C becomes sort of an optional > parameter, > the empty prefix being its default value. > src=A.B.C implies a 1-1 mapping between a srcdir and a module root, whereas A.B.C=src allows different modules (eg. all a project) to live in the same dir: Graphics.UI.Gtk=src System.IO.EEG=src Game.Flappy2048=src Conrad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
* Simon Marlow [2014-04-28 09:26:23+0100] > On 25/04/2014 17:57, Roman Cheplyaka wrote: > >* Edward Kmett [2014-04-25 11:22:46-0400] > >>+1 from me. I have a lot of projects that suffer with 4 levels of vacuous > >>subdirectories just for this. > >> > >>In theory cabal could support this on older GHC versions by copying all of > >>the > >>files to a working dir in dist with the expected layout on older GHCs. > >> > >>That would enable this to get much greater penetration more quickly. > > > >I'd really not want that people start putting ghc-options: -isrc=... > >into their cabal files. That'd make them irrecoverably ghc-specific, as no > >other > >tool will know how to process the files unless it reads ghc-options. > > No, the idea would be to use hs-source-dirs like this: > > hs-source-dirs: A.B.C=src > > Cabal just passes this in a -i option to GHC, so it almost Just Works, > except that Cabal needs to preprocess some source files so it needs to find > them, and also sdist needs to find source files. In that case, I'm in favour of this proposal. Please consider the reversed syntax instead: hs-source-dirs: src=A.B.C I find it more intuitive, because A.B.C becomes sort of an optional parameter, the empty prefix being its default value. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Thanks for all the feedback. Clearly opinion is divided on this one, so I'll sit on it and think it through some more. Cheers, Simon On 25/04/2014 14:17, Simon Marlow 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
Re: RFC: changes to -i flag for finding source files
On 25/04/2014 21:26, Malcolm Wallace wrote: On 25 Apr 2014, at 14:17, Simon Marlow wrote: 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, where the top few layers are all empty. I don't see how this is a problem at all. Navigating the "vacuous" structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: cabal, hoogle, haddock, happy, alex, hat, hsc2hs So actually many of these tools don't need to map module names to source files, so they work unchanged. Only Cabal definitely needs changes, I'm not sure about hoogle and hat but I suspect they would be fine. and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Fair enough :) Cheers, Simon Regards, Malcolm ___ 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
Re: RFC: changes to -i flag for finding source files
On 25/04/2014 17:57, Roman Cheplyaka wrote: * Edward Kmett [2014-04-25 11:22:46-0400] +1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. I'd really not want that people start putting ghc-options: -isrc=... into their cabal files. That'd make them irrecoverably ghc-specific, as no other tool will know how to process the files unless it reads ghc-options. No, the idea would be to use hs-source-dirs like this: hs-source-dirs: A.B.C=src Cabal just passes this in a -i option to GHC, so it almost Just Works, except that Cabal needs to preprocess some source files so it needs to find them, and also sdist needs to find source files. Cheers, Simon I'm +1 on adding support for this to cabal. Then the mechanism cabal uses to achieve this is just that — an implementation detail. And this new -i syntax can become one of such mechanisms. But cabal support should really come first, so that people aren't tempted by ghc-specific solutions. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Hi, > 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. +1 from me. The deep file system hierarchies imposed by the assumption that hierarchical module names need to be matched by a hierarchical directory structure has always bothered me (well, since hierarchical modules were introduced into Haskell some 15 years ago). In part because I do find it inconvenient, even if navigation arguably is not too hard, but more importantly because I think that language naming conventions in general should be as decoupled as possible from naming conventions of file systems/the mapping to how source code happen to be stored and organised on any particular system. While I do acknowledge the pragmatical convenience of essentially one-to-one mappings between module and file names, I think this proposal would be a step in the right direction, if feasible. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 15:17, Simon Marlow 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. > -1, too complicated for very little benefit ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 25 Apr 2014, at 14:17, Simon Marlow wrote: > 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, where the top few layers are all empty. I don't see how this is a problem at all. Navigating the "vacuous" structure is as simple as pressing the tab key a few times. But if you change the mapping convention between files and module names, you need to do it for all tools, not just the compiler. I imagine all of the following tools would need to know about it: cabal, hoogle, haddock, happy, alex, hat, hsc2hs and probably a few more. The feature seems like a very low power-to-weight ratio, so -1 from me. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 15:17, Simon Marlow wrote: [--snip--] -1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
-1 for me. In case that was unclear. On 25 April 2014 14:57, Alain O'Dea 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 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
Re: RFC: changes to -i flag for finding source files
> 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 > ...". My initial reaction is "not so excited". Personally, I favor convention over configuration + it makes tooling more complicated. But my personal preferences aside: - Will this lead to further fragmentation in the community (some will like it / some will hate it)? - If the paths are too complicated for a library author to manage, maybe that is an indicator that the imports are too complicate to manage for a user of that library, too? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
You can actually make symbolic links (as well as hard links and "directory junctions") on windows. -Edward > On Apr 25, 2014, at 12:51 PM, Roman Cheplyaka wrote: > > * Felipe Lessa [2014-04-25 13:01:43-0300] >> Em 25-04-2014 12:22, Edward Kmett escreveu: >>> +1 from me. I have a lot of projects that suffer with 4 levels of vacuous >>> subdirectories just for this. >>> >>> In theory cabal could support this on older GHC versions by copying all of >>> the files to a working dir in dist with the expected layout on older GHCs. >>> >>> That would enable this to get much greater penetration more quickly. >> >> What if you had a "real-src" directory with all your files as they are >> now, and a "src" symlink pointing inside your directory tree? > > I don't think Windows users can enjoy this, but it's a neat idea. > > Roman > ___ > 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
Re: RFC: changes to -i flag for finding source files
* Edward Kmett [2014-04-25 11:22:46-0400] > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous > subdirectories just for this. > > In theory cabal could support this on older GHC versions by copying all of the > files to a working dir in dist with the expected layout on older GHCs. > > That would enable this to get much greater penetration more quickly. I'd really not want that people start putting ghc-options: -isrc=... into their cabal files. That'd make them irrecoverably ghc-specific, as no other tool will know how to process the files unless it reads ghc-options. I'm +1 on adding support for this to cabal. Then the mechanism cabal uses to achieve this is just that — an implementation detail. And this new -i syntax can become one of such mechanisms. But cabal support should really come first, so that people aren't tempted by ghc-specific solutions. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On 2014-04-25 18:52, Edward Kmett wrote: > I check out and work on projects on a bunch of machines, so it is important > that I > can just pull with git and go. AFAIK, git doesn't understand them won't build > symlinks > for me, so it'd just become another setup step for very marginal benefit, and > another > thing to .gitignore. Git handles symlinks just fine. (Unless you're on Windows, I guess. I have no idea what it does there.) Regards, ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
I check out and work on projects on a bunch of machines, so it is important that I can just pull with git and go. AFAIK, git doesn't understand them won't build symlinks for me, so it'd just become another setup step for very marginal benefit, and another thing to .gitignore. -Edward > On Apr 25, 2014, at 12:01 PM, Felipe Lessa wrote: > > Em 25-04-2014 12:22, Edward Kmett escreveu: >> +1 from me. I have a lot of projects that suffer with 4 levels of vacuous >> subdirectories just for this. >> >> In theory cabal could support this on older GHC versions by copying all of >> the files to a working dir in dist with the expected layout on older GHCs. >> >> That would enable this to get much greater penetration more quickly. > > What if you had a "real-src" directory with all your files as they are > now, and a "src" symlink pointing inside your directory tree? > > Cheers, > > -- > Felipe. > > ___ > 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
Re: RFC: changes to -i flag for finding source files
* Felipe Lessa [2014-04-25 13:01:43-0300] > Em 25-04-2014 12:22, Edward Kmett escreveu: > > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous > > subdirectories just for this. > > > > In theory cabal could support this on older GHC versions by copying all of > > the files to a working dir in dist with the expected layout on older GHCs. > > > > That would enable this to get much greater penetration more quickly. > > What if you had a "real-src" directory with all your files as they are > now, and a "src" symlink pointing inside your directory tree? I don't think Windows users can enjoy this, but it's a neat idea. Roman signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Em 25-04-2014 12:22, Edward Kmett escreveu: > +1 from me. I have a lot of projects that suffer with 4 levels of vacuous > subdirectories just for this. > > In theory cabal could support this on older GHC versions by copying all of > the files to a working dir in dist with the expected layout on older GHCs. > > That would enable this to get much greater penetration more quickly. What if you had a "real-src" directory with all your files as they are now, and a "src" symlink pointing inside your directory tree? Cheers, -- Felipe. signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Em 25-04-2014 12:01, Mathieu Boespflug escreveu: > Such a policy violates the separation of provenance from function > principle, which I think is a good one. That is, I ought to be able to > swap in a different implementation of a map for the standard one in > the containers package without having to touch my code (especially if > the exported API's happen to match). The work being done on Backpack seems like a much better solution than creating packages that export modules with the same names. http://plv.mpi-sws.org/backpack/ Cheers, -- Felipe. signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
+1 from me. I have a lot of projects that suffer with 4 levels of vacuous subdirectories just for this. In theory cabal could support this on older GHC versions by copying all of the files to a working dir in dist with the expected layout on older GHCs. That would enable this to get much greater penetration more quickly. -Edward > On Apr 25, 2014, at 9:17 AM, Simon Marlow 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.h >... > > 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
Re: RFC: changes to -i flag for finding source files
On Fri, Apr 25, 2014 at 05:01:21PM +0200, Mathieu Boespflug wrote: > That is, I ought to be able to swap in a different implementation of a > map for the standard one in the containers package without having to > touch my code (especially if the exported API's happen to match). That's certainly a nice property, but how often have you really used it? I just don't think that the current naming schemes will scale nicely. If more people will use Haskell, then there's a need for separating namespaces. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On Fri, Apr 25, 2014 at 4:46 PM, Daniel Trstenjak wrote: > On Fri, Apr 25, 2014 at 07:16:03AM -0700, Eric Seidel wrote: >> 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. > > I think several of the issues might be resolved by just using the package name > as the first module name. Such a policy violates the separation of provenance from function principle, which I think is a good one. That is, I ought to be able to swap in a different implementation of a map for the standard one in the containers package without having to touch my code (especially if the exported API's happen to match). -- Mathieu Boespflug Founder at http://tweag.io. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
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 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
Re: RFC: changes to -i flag for finding source files
On Fri, Apr 25, 2014 at 07:16:03AM -0700, Eric Seidel wrote: > 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. I think several of the issues might be resolved by just using the package name as the first module name. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
On Fri, Apr 25, 2014 at 10:16 AM, Eric Seidel wrote: > The main con here is that there's an increased risk of > module name-clashes, but GHC already solves this with the PackageImports > extension. IMO almost any use of PackageImports indicates a severe design flaw somewhere. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
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 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 > -- Sent from Gmail Mobile ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: changes to -i flag for finding source files
Hi Simon, I don't quite know what I should think about this addition. Currently you can be sure that modules correspond to directories. After this change you can't be sure anymore. I don't navigate source trees that much by 'cd'-ing into single directories, so deep hierarchies don't bother me that much. There're certainly good intentions in the naming schemes of Haskell modules, but sometimes they just feel a bit forced. So for the module name 'Graphics.UI.Gtk' I might just have chosen the name 'Gtk'. If the library itself wants to separate code into several modules, then the module names can get quite bulky. So using module names to origanize the code and to classifiy its meaning might be a bit too much. Well, just some thoughts. Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
