Yhc/Path handling

Part of Yhc (Download)

I currently find Yhc's path handling deeply annoying, so here's my plan for revising it :)

Some Notes

Incorporate some Jhc extensions

I think this was from Jhc, but I seem to have lost the reference :)

The module Data.Map can be found at either: Data/Map.hs OR Data.Map.hs

This is great because it allows to flatten directory structures. I don't think this is particularly useful for storing source files, but is great for putting .hbc files for one project, all in one directory!

Auto-package compiling

Sometimes I will be working on a program, and a package concurrently. I'll put the package in my packages directory, and just compile my program. This currently puts the .hbc for the package in my program directory - totally the wrong place.

Read only library directory

This might be a problem on Unix, which is annoying. Solution is to try and write out a package in the same directory, if that doesn't work then put it in the current path.

Auto stupid-naming

If i compile a file called Hoogle.hs, which is given as module Main, I want hoogle.hbc, not main.hbc. Especially if I have many files which are module Main in one directory, they keep overwriting each other. GHC also gets this wrong, by default every windows binary comes out as Main.exe, woot...

Solution

Be as automatic as possible!

I recommend the introduction of a hoogle.ini file or some such, to store some of these preferences, but keeping it to a minimum. This is better than an environment variable. This could also replace YHC_BASE_PATH. If the ini file does not exist (and I would hope that its existance IS rare), then very sensible defaults will be picked, calculated based on the existing system.

When compiling a package module, if at all possible, it will be put in the package directory. This means all programs can use it, and it reduces clutter. If it can't be (i.e. it gets a complaint) then a warning will be given (you're duplicating work), and it will be stored in the application directory.

When compiling an application module, there should be two standard options:

Side by side

This is the current one

Main.hs -> Main.hbc MyApp/Bob.hs -> MyApp/Bob.hbc

One Directory

Main.hs -> Main.hbc (module Main) Hoogle.hs -> Hoogle.hbc (module Main) Hoogle.hs -> hbc/Hoogle.hbc (module Hoogle) MyApp/Bob.hs -> hbc/MyApp/Bob.hbc (module MyApp.Bob)

Notes

I would personally prefer the one directory approach, and suggest it should be default. Side by side is more traditional, but I'd say thats a lousy argument. One Directory has a few advantages, primarily less cluter and easier telling what is your source vs not! It would require a change to the search mechanism to ensure that Path/hbc is considered the same directory as Path.

Perhaps another advantage of the /hbc approach is that by changing the /hbc prefix, to say /hat, you can keep two versions of your program around at the same time with different build options? Perhaps if this is the case, Main.hbc should also be put in /hbc? This has the disadvantage that the Main.hbc is not immediately discoverable, but maybe its worth it?

Perhaps Main.hbc should be created for /hbc prefix, and Main.hat.hbc should be created for /hat prefix? That would solve the above issue quite easily and simply, and means two entirely different optioned versions of the program could be stored at the same time. Plus its still discoverable.

.hi should be stored next to the .hbc, unless there is a special policy for module Main, in which case it should go where an ordinary module would have gone.

Thoughts?