Support Mod.hs files?

I might be completely and utterly wrong here, but isn’t this achievable if we break the whole compilation unit = file = module thing, specifically the file = module part?

I imagine if you had the file Foo/Mod.hs and then Mod.hs looks like this

module Foo where

Would that achieve what OP is asking for?

Not to imply at all that it’s so easy to do or anything, just asking theoretically

…because they addressed two separate points:

  • The first one posed an alternative solution: a new directory to hold those “logically-related” modules, to avoid them “getting forced into different directories”.

  • The second one was speculative: if per-directory Mod modules were used everywhere (much like what some seem to be doing with -XBlockArgument) would we be happy with that, or would constantly seeing all those Mod suffixes be irritating?

As for the now-broken URL:

…look for the response starting with:

“It shouldn’t be too complex” is sadly optimistic […]

GHC also supports naming your file Foo.Bar.Mu.hs and skipping the directory structure, which I prefer, but a large amount of tooling assumes the Foo/Bar/Mu.hs convention. So in practice if you want people to enjoy collaborating with you there isn’t a choice.


I’ve read that before, but that doesn’t work for me with GHC 9.4.6:

$ cat Foo.Bar.Mu.hs 
module Foo.Bar.Mu where

x :: Int
x = 10

$ cat Test.hs
import Foo.Bar.Mu
main = print x

$ runhaskell Test.hs

Test.hs:1:1: error:
    Could not find module ‘Foo.Bar.Mu’
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
1 | import Foo.Bar.Mu
  | ^^^^^^^^^^^^^^^^^

I see; it’s been some years since I encountered this, so it may have worked accidentally, on an older version, or by some unusual interaction with Cabal or Stack. :+1:

To me this looks like Python’s files which can be used to control exports from a “package” (directory). But afaik, Python is moving away from this pattern.

1 Like