[Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?

Ketil Malde ketil at malde.org
Tue Nov 24 08:35:35 EST 2009


Ben Millwood <haskell at benmachine.co.uk> writes:

>> E.g. if module Foo.Bar isn't found in Foo/Bar.hs GHC could look in
>> Foo.hs (which would just contain a concatenation of what would currently
>> reside in Foo.hs and Foo/Bar.hs).

> The obvious question arising here is what if module Foo.Bar *is* found
> in Foo/Bar.hs as well as in Foo.hs - is the latter ignored?

I would suggest this situation to be an error, but ghc currently appears to
handle ambiguitiy by picking the first one that fits (according to my
experimentation with multiple source directories and the -i option).

> It doesn't sound like an insurmountable problem but one of the nicest
> things about the current module system is its simplicity and predictability,
> both of which are somewhat attacked by this proposal.

As mentioned, there is already ambiguity, but of course this proposal
would increase the number of paths to search.

> Also, it sounds like your proposal would disallow definition of
> multiple top-level modules in a file, because we wouldn't know where
> to look for them.

Yes, I don't see how to do that either, unless you introduce a
generalized --main-is option, or similar.

(Speaking about which, one obvious exception would be that the file
Foo.hs could contain the Main module in addition to any modules in the
Foo.* hierarchy.  So it'd allow more structure to single-file
applications. For what it's worth.)

> Presumably having the modules together in a file would also mean that
> they could only be compiled together and would produce a single .o or
> .hi file. 

Not sure about that, you'd still be able to build multiple .o/hi's, and
conditional compilation could be done by checksumming the indidual
modules.

Anyway, I think the main use-case here is for multiple small modules,
so the impact on compile times might even be positive (for trivial
modules, the compile time might be dominated by the IO operations).

> This is not to say I'm against the proposal, but it's probably not as
> clear-cut as it sounds.

Thinking about it, I guess I'm really wanting to address a weakness in
my development system (namely that it is cumbersome to work with a
myriad of tiny files). And it occurs to me that the compiler might not
be the appropriate place to do solve this.

-k
-- 
If I haven't seen further, it is by standing in the footprints of giants


More information about the Haskell-Cafe mailing list