Temporarily overriding Data.Generic

[Duncan Coutts]

On Thu, 2009-02-05 at 00:11 +0100, Deniz Dogan wrote:
> I'm currently working on "hacking" Data.Generics for my master thesis.
> I'm basically trying to find out whether it can be made any faster
> using e.g. rewrite rules. The problem I'm having is that I need an
> easy way to import my own modified version of Data.Generics (currently
> located in the same directory as my testing program) without
> unregistering or hiding syb-0.1.0.0 as base seems to depend on it.

This should just work. If ./Data/Generics.hs exists in / relative to the
current directory then by default that overrides the module of the same
name from the syb package. There's clearly some specific problem you're
hitting, can you tell us more about it?

When you say "currently located in the same directory as my testing
program" do you mean you've got Generics.hs in the same dir as your
Test.hs module or do you mean you've got ./Test.hs
and ./Data/Generics.hs, ie in a subdirectory?

The problems you're likely to run into will be with other code that
already uses the syb:Data.Generics module as the types are necessarily
not substitutable for each other.

> I've read the GHC user manual trying to find nice ways to do this
> using a bunch of different parameters to ghc, but I can't figure it
> out. Does anyone here know?

The command line options for controlling the module search path are
basically the -package flags and the -i flag. The default if you don't
say anything is -i. meaning look first in the current directory.

Duncan