CVS / directory re-organization

[Brian T Rice]

You all may have noticed a lower-than-usual level of CVS activity in the
last week. I've been writing up a lot of new sources, but not committing
them, since there's a re-organization that is starting to appear
necessary. I'll explain the issues:

Currently, we have this directory structure:
doc/ - any documentation
etc/ - any extra files for convenient environment setup
site/ - the web site
src/ - any code in Slate
  bootstrap/ - self-hosted system setup (implementation-level)
  compiler/ - misnomer: the parser, or AST-manipulator, really
  graphics/ - partial misnomer: this is the UI toolkit
    X11/ - the UI toolkit's X11 backend
  mop/ - the meta-object protocol. it's only a sketch right now
  optimizer/ - the IR and MR frameworks for binary code generation
  vm/ - the bytecode VM code, along with the bytecode compiler and runtime

Right now, I'm looking at a C backend (src/c/ not checked in) and the VM
code, and realizing that a different organization for src/ would help out.
This is what I have in mind:

src/
  mobius/ - anything related to self-hosting
    optimizer/ - the IR/MR chain and all the optimization code that
                 manipulates them
    backend/ - (eventually) code generators for the IR/MR compiler
    c/ - not a backend for IR/MR necessarily, so it's separate
    mr/ - a separate MR framework for representing machine characteristics
    syntax/ - the parser and AST-manipulation libraries
    vm/ - bytecode VM and related implementation code (and bytecode compiler)
  mop/ - still the MOP for now
  ui/ - the UI framework
    ports/ - the backends for the rendering and event management
      X11/ - for X11
      vt100/ - for terminals ("terminal/"?)

mobius/ refers to the name for the compiler ideas that Lee and I had a
long time ago. The purpose of that section is to categorize the
implementation strategies and sections, and to abstract over them; the
general idea is to present a facade and describe the common fundamentals
apart from any specific setup. An example is that the type system and type
inference framework are currently defined in src/compiler/ currently, but
does not belong in syntax/ and is certainly needed for all the
implementation strategies.

mr/ is anything but instruction-set issues. The IR/MR pair are strictly
about code optimization, although large-scale platform characteristics
still apply. This won't be filled in immediately, and is up to Lee to use.

syntax/ would include the lexer, parser, syntax definition, macro system,
and anything else that is about source, templates, annotation, or
whatever.

vm/ will include the bytecode compiler that i'm working on, the bytecode
vm definition that will get translated to C, whatever plumbing support is
needed to make the VM work stand-alone, and whatever else is related.

c/ includes a relatively-simple C translation layer, and potentially would
include some simple setup for parsing header files for signatures to
libraries. This will exist independently of the MR layer, although MR->C
is not out of the question, it's just not taking priority until IR->MR is
done, and the C framework will be re-usable.

ui/ will obviously include all the user interface code, and shouldn't get
so complex that i'd need several subdirectories aside from the various
backends, called "ports".

...

Well, that's a broad outline. Let me know about name suggestions or
additions to this.

When I do this, you'll have to separate or submit any local changes you
have just to be safe, since there will be a huge amount of file movement,
and it'd be easy to forget some detail and lose work.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/