RFC: changes to -i flag for finding source files

older
GHC 7.8.2 bindist for OS X with...

Simon Marlow

25 Apr 2014 25 Apr '14

9:17 a.m.

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

Show replies by date

Daniel Trstenjak

25 Apr 25 Apr

10:08 a.m.

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

Eric Seidel

10:16 a.m.

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

Brandon Allbery

10:34 a.m.

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 allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Daniel Trstenjak

10:46 a.m.

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

Mathieu Boespflug

11:01 a.m.

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.

Daniel Trstenjak

11:14 a.m.

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

Felipe Lessa

11:59 a.m.

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.

Alain O'Dea

10:57 a.m.

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

Alain O'Dea

2:56 p.m.

-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

Edward Kmett

11:22 a.m.

+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

Felipe Lessa

12:01 p.m.

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.

Roman Cheplyaka

12:51 p.m.

* 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

Edward Kmett

12:54 p.m.

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

Edward Kmett

12:52 p.m.

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

Bardur Arantsson

1:02 p.m.

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,

Roman Cheplyaka

12:57 p.m.

* 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

Simon Marlow

28 Apr 28 Apr

4:26 a.m.

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

Roman Cheplyaka

4:40 a.m.

* 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

Conrad Parker

7:23 a.m.

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.

Alois Cochard

7:47 a.m.

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

Simon Hengel

25 Apr 25 Apr

1:34 p.m.

...

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

Bardur Arantsson

3:50 p.m.

On 2014-04-25 15:17, Simon Marlow wrote: [--snip--] -1

Malcolm Wallace

4:26 p.m.

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

Simon Marlow

28 Apr 28 Apr

4:33 a.m.

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

Sven Panne

8:10 a.m.

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.

Bardur Arantsson

26 Apr 26 Apr

2:54 a.m.

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

Henrik Nilsson

7:18 a.m.

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 nhn@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.

Simon Marlow

28 Apr 28 Apr

4:35 a.m.

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

Simon Hengel

29 May 29 May

10:27 p.m.

...

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.

John Meacham

30 May 30 May

5 a.m.

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/

Krzysztof Skrzętnicki

5:05 a.m.

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

...
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

On Fri, Apr 25, 2014 at 6:17 AM, Simon Marlow wrote: 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

Daniel Trstenjak

5:45 a.m.

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

John Meacham

6:10 a.m.

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/

Simon Marlow

3:59 p.m.

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

Herbert Valerio Riedel

6:10 a.m.

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

6:13 a.m.

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/

Bardur Arantsson

10:46 a.m.

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,

4008

Age (days ago)

4043

Last active (days ago)

List overview

Download

37 comments

19 participants

participants (19)

Alain O'Dea
Alois Cochard
Bardur Arantsson
Brandon Allbery
Conrad Parker
Daniel Trstenjak
Edward Kmett
Eric Seidel
Felipe Lessa
Henrik Nilsson
Herbert Valerio Riedel
John Meacham
Krzysztof Skrzętnicki
Malcolm Wallace
Mathieu Boespflug
Roman Cheplyaka
Simon Hengel
Simon Marlow
Sven Panne