packaging.groovy

// [=] instructions denote the boundary between one model and another.
// the traverser's model will have a different algebra than the model its moving through.
//   - e.g. the internal state of the traverser uses different types than mongodb.
//   - how do traversers split at branches?
//   - how do traversers merge at joins?
//   - when traversers merge, what are the rules for path aggregation?

// Perhaps [=] instructions are "rich" in that they store model definitions. (costume change)
// This could be how progamming libraries are expressed in mm-ADT?               
                        
// In this way, the user creates a traverser specification as such:                          

[branch,[=pathing],[=group],[=mongo]]
          
// ....where, for large programs, these model libraries are defined elsewhere (file-wise). 
// For instance, the VM might have access to a models/ directory.
    
// group.mm  "jar" :)
[=group,[choose,
         [plus,[zero]]   -> [id]
         [minus,[zero]]  -> [id]
         x + y           -> y + x
         --x             -> x]]

// pathing.mm 
[=pathing,[choose,
           [get,'path']  -> [;]
           inst          -> [get,'path'][add,[get,'value']]]]

// to bundle these models into a single [=] would be:

// myapp.mm
[=mymonad,[branch,[=pathing],[=group],[=mongo]]]  // define once for many many queries to follow

// That was all application development stuff. 
// Now to execute queries (what most users will experience).
// A query over mongodb where path histories are recorded and group axioms are applied.

[=mymonad][get,'people'][is,[get,'name'][eq,'marko']][get,'age']