Proposals for changes to searching behaviour

[Simon Marlow]

> > >     I'm not sure what syntax we'd use for this.  Henrik suggested
> > >     placing the module prefix in square brackets before=20
> the directory,
> > >     eg.
> > >         ghc -i '-i[Graphics.Rendering.OpenGL].'
> >=20
> > This seems a bit unpredictable to me; it means that you can
> > have a whole bunch of unrelated modules sitting together in the
> > same directory, and then confuse the user even more with obscure
> > GHC commandline switches :).
>=20
> First, the point here is to reduce the number of assumptions=20
> built into
> a Haskell system about where sources live and what they are called.
> The fewer assumptions that are made, the greater the likelyhood that
> it will interoperate smoothly with other tools. Try to use the current
> mapping from hierarchical module names to file names with the Make
> VPATH mechanism for an example of what I mean.

I've never quite managed to figure out what VPATH is for; one reason is
that I've never got it to cooperate well with automatically-generated
dependencies.  If there's a specific restriction in GHC that prevents
the use of VPATH, could you describe what it is?

> > I'd argue that if you have a Graphics.Rendering.OpenGL module,
> > you should make it 100% obvious that the module is in
> > a Graphics.Rendering category; either putting it in a
> > Graphics/Rendering directory or having
> > a Graphics.Rendering.OpenGL.hs file makes this explicit.
>=20
> I see little merrit in having a Haskell system enforce such rules.

It comes down to this: the Haskell system has to find files (normally
interface files).  Either these files are named according to a simple
convention, or you have to tell the compiler more about where they live.
You would rather we moved towards the latter position.

There's a compromise (well sort of).  If you don't need to use --make,
then GHC will let you use whatever filenames you like for the sources;
the only restriction is that it has to be able to find the interfaces,
so you have to arrange they get placed where GHC can find them either by
using the -ohi flag or by having the build system move them. =20

Even if you do need to use --make or GHCi, then I think you can still
specify all the source files on the command line. =20

Actually, I've just tried this and it almost works.  The interface files
get put in the current directory and have all but the last component of
the module name stripped off, which is fine as long as you don't have
any other modules with the same last component.  I think perhaps fixing
this and documenting the behaviour would be a good step forward.  Then
would there be any reason to need the other extensions?

Cheers,
	Simon