strappy_directory_structure

Redesigning the Strappy code base architecture

Proposal One

We want to facilitate development of code that implements the core program induction algorithms while simultaneously using this code to run experiments in various domains. It would be best if the code bases for these uses was as distinct as possible. Also, we want to relate publication related stuff to the code that supports it. I propose the following structure:

• core /
• strappy-core.cabal
• src/
  • Strappy/
    • Core/
      • EC/
      • Analysis/
      • Utils/
      • etc... (other supporting code).
• projects (directories for individual projects)
  • morphology (a publication specific directory)
    • strappy-morphology.cabal (a separate cabal library for this project)
    • drafts/
    • bib/
    • tex/
    • src/
      • Strappy/
        • Number.hs
        • etc.
  • number
• etc...

Proposal Two

Another way we might maintain a strict separation between the core E.C. algorithm and projects which apply E.C. is through the use of [git submodules](http://www.git-scm.co\ m/book/en/Git-Tools-Submodules), or better yet, just via cabal. These projects can use Strappy as a submodule or mark Strappy as a dependency without being tightly coupled as part of the same repository. They can also maintain application-specific executables, primitives & libraries, publication material, and so on. In that case, the resulting file system might look like this for E.C. itself:

• /
  • strappy-core.cabal
  • Setup.hs
  • LICENSE
  • README
  • test /
  • drafts /
    • bib /
    • tex /
  • src /
    • Strappy /
      • Core /
        • EC /
        • Analysis /
        • Utils /
        • etc...
    • Numeric /

and like this for a project using E.C. (i.e. morphology, number, noun phrases):

• /
  • <project>.cabal
  • Setup.hs
  • LICENSE
  • README
  • <Project> /
    • drafts /
      • bib /
      • tex /
    • test /
    • src /
      • <Project>.hs -- application-specific libraries, tasks, and simulations
      • etc ...