Proposals for changes to searching behaviour

[nilsson@cs.yale.edu]

Hi Andre,

> I like this idea, especially if this is currently the way Hugs
> does it.  It's great for smaller projects.

Yes, we believe Hugs does allow "A.B.C.hs" as well as "A/B/C.hs".

Ultimately, I think it is actually going to quite important that the
different Haskell tools provoide reasonably compatible ways of finding
sources/libraries. That includes the mechanisms discussed here as well as
a package mechanims.

> >     I'm not sure what syntax we'd use for this.  Henrik suggested
> >     placing the module prefix in square brackets before the directory,
> >     eg.
> >         ghc -i '-i[Graphics.Rendering.OpenGL].'
> 
> 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 :).

First, the point here is to reduce the number of assumptions 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.

Second, I don't think this particular example of command line syntax
is that obscure. Being able to tell GHC (and ultimately, I would hope,
other Haskell implementations), what part of the module hierarchy they
can find along a certain search path seems quite natural to me.

> 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.

I see little merrit in having a Haskell system enforce such rules.

When dealing with large systems possibly involving many different
languages and tools, it is very hard to predict what kind of source
structure that is going to be most suitable and most easy for someone
to get familiar with.

Ultimately, the person(s) implementing an application/library is/are the
one(s) best qualified for making such decisions, and the tools should
ideally support that (within reason), not get in the way.

Furthermore, different people might have different opinions on what's
obvious, or what's the best tradeoff betweem "obviousness"/conveniece.

> To put it another way -- is there a situation where you don't
> want to use either of the above two module naming schemes, and
> can justify having unrelated modules in an arbitrarily organised
> directory structure?

Well, again, ultimately I think the application/libabry implementor(s) should
gave the ultimate say as to how to organize his/her/their sources, and
what files that are sufficiently related to be put in a single directory.

One reason I don't particularly like the "A/B/C" scheme, is that my sources
can end up being spread out over several directories just because of the
names I happen to choose for the modules. If, say, a library consists of
the top-level module "A.B.C" and a bunch of internal components
"A.B.C.M1", "A.B.C.M2", etc., I can't see why I should not be allowed
to put them all in one directory. Another reason is how it interacts
with tools like "Make". I've already mentioned the VPATH mechanism.
Other make facilities like its (as well as the invoked shell's) wildcard
support for file name matching also becomes much less useful.

The reason I'm not quite happy with "fully qualified" file names, is that
they could become inconveniently long, and that it still can make sense
to use directories for part of the module hierarchy.

I think the two suggestions ("." as an alternative to "/", and the
possiblity to associate a search path with a module prefix) complement
each other quite nicely, yielding a scheme which lets the implementors
decide how to best organize their source code.

/Henrik

-- 
Henrik Nilsson
Yale University
Department of Computer Science
nilsson@cs.yale.edu