How Mesquite works

Mesquite operates via the cooperation of modules, each of which performs some function or duty. There is one core module, the Mesquite trunk module. When this module starts up, it finds all of the available modules. (Mesquite does this by looking into the subdirectories of the mesquite directory.) From each module, it gathers information, including its name and the functions the module promises to perform.

A programmer's account of Mesquite's modular architecture is given in the developer's documentation.

The tree of modules

Modules are "hired" by other modules as employees to perform certain tasks. Thus, the core Mesquite module hires a "File Coordinator" module to manage most activities, including coordinating the reading and analyzing of data files. The File Coordinator itself hires other modules to do the actual file reading and analyses. The file reading module may hire other modules to handle particular parts of the data file, one for the data matrix, another for the trees, and so on.With modules hiring modules hiring modules, the modules in use at any time are linked together in employee-employer relationships that as a whole take the form of a tree, with the root module being the core Mesquite trunk module. (To see the tree of modules active at any time, choose the menu item "Active Modules" from Mesquite's Help menu, or by touching the Modules tab in a window's information bar.)

Here is a diagram of a section of the module tree. The five modules in the oval are engaged in calculating and presenting some result to the user. (The two modules outside the oval are patiently waiting as alternatives.) The over-all coordinator module has hired a calculation coordinator module, which in turns uses one module to supply data and another to do the actual calculation. The over-all coordinator also hires a module to display the results (in this case, a charting module).

Kinds of modules: Duties

A module will decide which other modules would be appropriate to hire for a particular task according to the duties that the various modules promise to perform. Each module belongs to a particular kind of module, and these kinds amount to a claim as to what duties will be performed. (Technically, these "kinds" are subclasses of the general Mesquite module class, and a particular module can choose which kind it is by what subclass it extends.) For instance, one "kind" of module is a DrawTree module. By belonging to this kind, a module promises that, when given a tree, it will draw it. There may be multiple DrawTree modules available -- one may make square trees ("phenograms"), another diagonal trees ("cladograms"), another circular trees, another may plot the nodes of the tree in a three dimensional space, and so on. The fact that a module is of the DrawTree kind guarantees to any employer module that it will perform a task in a predictable way, and be interchangeable with other modules of the DrawTree kind. If a module needs a tree drawn, it could choose any one of these DrawTree modules to hire. Modules can easily fire an existing employee, and hire a new one, to respond to a user's request to change the calculation or display.

Consequences to the user: Flexibility and choice

This system of modules provides great flexibility for the user in designing calculations and output. The user can typically choose which particular module of a kind is used, and thus mix and match modules to construct an analysis. In the example of the illustration, the user might substitute the other calculation module (calculation 2) and the other graphical display module (table) and thus arrive at a different calculation and output. If, in the future, someone writes a new sort of calculation module (calculation 3), it can also be plugged in to the system as a new alternative. It can be used not only in the calculation diagrammed above, but in any other analysis in which a calculation of its basic kind is needed. Likewise, if someone writes a new sort of graphical presentation module, it can also be plugged in. This means that the number of alternative analyses and display modes available to the user rises multiplicatively as more modules of different kinds are available.

The diversity of analyses that can be done with Mesquite is valuable in many respects, not the least of which is that it helps overcome the constraining effect that computer programs tend to have on a user's work. However, it also forces the user to make choices: to think about exactly what he or she is doing. This may be an advantage or disadvantage. Of course, one could write an artificial intelligence module that advises the user what to do....

It is not just the diversity of analyses that makes Mesquite unusual. It is the fact that we cannot predict what features it will have, since its features depend on the modules currently installed and loaded. Thus, a simple manual for it is not possible. In a normal program we could say "If you want to trace a character, go to the Analysis menu and choose Trace Character. The branches will be shaded to show the parsimonious ancestral states". With Mesquite, the branches might not be shaded, because the reconstructed states might be displayed in some other way, according to whatever display module is in use. The states might not be reconstructed by parsimony. The Trace Character command might not appear in the Analysis menu, since the Trace Character module might be hired by various other modules, and each of these employer modules might choose a different place (e.g., somewhere other than a Trace menu) to give the user the opportunity to choose analyeses. We have attempted to describe standard analysis via the links at the left hand side of this page. Beyond those, however, the user can use the examples files for more information about setting up analyses.