NOTES

Some notes about the RX code

Here are some random thoughts to help understand and navigate the RX code.


PACKAGE ORGANIZATION
The main package rx is for "library" type routines.
The subpackage rx/rxsys holds library routines not acceptable in web apps.
Most of the significant code should go in the library;
utility programs should just provide an interface to the library.
Subpackages rxplor, rxquest, etc implement command-level programs.
Subtree webapp implements the regex.cs.arizona.edu website.

VISIBILITY
[Recall: Capitalized symbols are exported from a package.]
Not everything capitalized should be considered an external "feature".
Some things are exported for access by debugging printfs in commands.
Parse tree node fields must all be exportable to be "gobbable".

STRUCTS
Structs are uniformly passed by reference (as pointers), not values.
[Interface types such as Node and error are pointers without explicit '*'.]

CODING STYLE
Code is formatted according to the standard Go rules.
"go fmt" should be run before any check-in.
There is a "pre-commit" Git hook available to check this.
Lines should be limited to 80 columns for better human comprehension
(even though we're not limited to punch cards or fixed-width terminals).

COMMENTING
Terminology is based on the "Dragon book" [Aho & Ullman 1977].
Struct, func, and package comments should work with "godoc"
(so: no blank line between header comment and struct or func).