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.
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 j...@repetae.net 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
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
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,
On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak
daniel.trsten...@gmail.com 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
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
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
On 30/05/14 11:10, John Meacham wrote:
On Fri, May 30, 2014 at 2:45 AM, Daniel Trstenjak
daniel.trsten...@gmail.com 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
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
On 25/04/2014 17:57, Roman Cheplyaka wrote:
* Edward Kmett ekm...@gmail.com [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
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.
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
* Simon Marlow marlo...@gmail.com [2014-04-28 09:26:23+0100]
On 25/04/2014 17:57, Roman Cheplyaka wrote:
* Edward Kmett ekm...@gmail.com [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
On 28 April 2014 18:40, Roman Cheplyaka r...@ro-che.info wrote:
* Simon Marlow marlo...@gmail.com [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,
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
2014-04-25 22:26 GMT+02:00 Malcolm Wallace malcolm.wall...@me.com:
[...] 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
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
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
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
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,
On Fri, Apr 25, 2014 at 10:16 AM, Eric Seidel gridaph...@gmail.com 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.
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
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
On Fri, Apr 25, 2014 at 4:46 PM, Daniel Trstenjak
daniel.trsten...@gmail.com 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
+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
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
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
* Felipe Lessa felipe.le...@gmail.com [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
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
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
* Edward Kmett ekm...@gmail.com [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
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 r...@ro-che.info wrote:
* Felipe Lessa felipe.le...@gmail.com [2014-04-25 13:01:43-0300]
Em 25-04-2014 12:22, Edward Kmett escreveu:
+1
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
-1 for me. In case that was unclear.
On 25 April 2014 14:57, Alain O'Dea alain.o...@gmail.com wrote:
I have trouble with this as it breaks expectations around directory
structure mirroring the module hierarchy.
I would be very confused reading the source code of a project that availed
of
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
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.
36 matches
Mail list logo
