Hi, There are only few hours until the deadline, but I still have some hope to receive comments to improve my proposal. The goal of the project I am intending to do is to develop a working prototype of a make-style module/file dependency framework for the Cabal, which is the most actively evolving Haskell build system at the moment. At this time building process with Cabal is somewhat imperative and depends on GHC's "--make" option or hmake when building modules written in the Haskell language. Thus, new dependency system should support its own module chasing from a description given the declarative style, which would give a possibility to add many new features and resolve old bugs in the Haskell Cabal (as there are currently more than 10 tickets which depend on the dependency tracking implementation). Pre-processors (c2hs e.g.) and some other Haskell compilers, which don't have their own dependency system, would greatly benefit from this improvement. Gtk2hs will also greatly benefit from this project, as at this time it uses shell language and limited functional language on top (make) for its build system which prevents handling of dynamic dependencies in the right way. Absence of dependencies tracking in Cabal prevents gtkhs to be cabalised fully. Getting some ideas from the first sketchy prototype we can see that dynamic dependencies should be supported, i.e. some actions can be run while computing the dependency graph. The plan to deploy the code of the project in the real use cases is to code dependency resolver for yhc or nhc98 (depends on the difficulty of integration with existing compiler codebase). Doing this won't hurt ghc support, which is quite important. The great part of the work is contriving an embedded domain specific language for the make actions specification. This will reduce complexity, role of imperative parts and code size of Cabal in general. The form of this EDSL needs careful investigation. The system should be fairly generic and extensible for actions and rules to be expressed crearly. Framework can be customised with pre-processors or other actions which are run in the process of the dependency resolving. For the aid in testing and clarifying project goals some sophisticated examples will be constructed (using pre-processors, cases with search path shadowing etc). Seeing the existing problems we can decide how to improve Cabal for their resolution. With the help of parametrisation over a type of used monad for actions we can do tests without any IO through QuickCheck. Do you think there are some things in this abstract I should remove or I should definitely add? Are there some wrong assumptions or things that can go beyond my project? Thanks for advance for any advice, comment or question. -- Max