Question

I’ve a function evalExpression :: Exp -> Value in a module A that depends heavily on pattern matching over the argument Exp.

The file has become large enough to desire more organization. I’d like to split the module A into modules A.GHC.Num, A.GHC.Types, etc.

• Is there a way to inline a module inside another one in GHC? I tried doing this but I get the error “Module imports form a cycle”

or

• Is there a way to write the same module in two different files?

or

• Can I define a function A.evalExp that tries (in the sense of try and catch) to return the value of A.GHC.Num.evalExp and if it caches an error (non-exhaustive pattern match), tries to return A.GHC.Types.evalExp, and so forth?

Update:

I tried solving the cyclic dependency but GHC was not convinced, it says “Ambiguous occurrence”.

Answer 1

No, you can’t split a module between multiple files, and you certainly can’t define a function in different locations. The closest thing to this is a function that’s part of a type class, with instances defined in various modules. But that’s probably not what you want here.

However, it is possible to compile mutually-recursive modules. In theory this should Just Work ™ but GHC requires a bit of hoop jumping to do it; see the User’s Guide for details. If you were getting a cyclic module import error, this should let you make that version work.

There’s no “nice” way to catch an inexhaustive pattern match error and try something else. There are multiple not-so-nice ways, but you probably don’t want to go there.

If your goal is pattern-matching on a single data type with lots of cases, the most straightforward way to split things up without messing with mutually recursive modules or type classes would be to have separate functions in other modules that take the contents of each constructor as direct arguments, then a single pattern-match on all cases in a modules that imports the others and does the dispatch.

Say you have a type Foo with cases A, B, &c., with similarly named modules. In the “central” module you could have:

doStuff (A x y) = A.doStuffA x y
doStuff (B z) = B.doStuffB z

…and so on.

In some scenarios, it even makes sense to split the entire data type up in a similar way, and create a separate type for each constructor, e.g.: data Foo = A FooA | B FooB | .... This is most useful when you have a complicated tangle of data types that may be mutually recursive in multiple ways, the classic example being an AST.

---

Okay, here’s one way to simulate what you want without doing anything too sketchy.

First, split your function up into different modules in the way you’d ideally want. Then make the following changes:

• Change the result type to use Maybe, wrapping results in Just and adding a catch-all default case that produces Nothing.

• Add an extra argument r, and replace any recursive calls to evalExp with r.

From a central module, import each module that contains evalExp cases. Use a qualified import if necessary to avoid ambiguity. Define a list of each eval function (they should all have the same type), then define the “real” evalExp as something like this:

expCases = [A.GHC.Num.evalExp, A.GHC.Types.evalExpr {- etc... -} ]

evalExpCases exp = mapMaybe (\eval -> eval evalExp exp) expCases

evalExp exp = case evalExpCases exp of
                  (r:_) -> -- use the first result 
                  [] -> -- no cases matched

Essentially, this is using Maybe to indicate inexhaustive patterns explicitly, and replacing the direct recursion with a fix-style construction where the combined, recursive function is passed in to each (individually non-recursive) set of cases.

It’s pretty awkward, but I’m not sure there’s really any better way. There might be a way to automate all that crap using Template Haskell, but that’d probably be just as much hassle as doing it manually.

Personally, I’d probably just grit my teeth and leave it all in one module.