mm-adt-play.groovy

mmadt> '2' => [is,[or,[a,int],[eq,1]]][mult,6]
mmadt> 2.3 => [is,[or,[a,int],[eq,1]]][mult,6]
mmadt> 6 => [is,[or,[a,int],[eq,1]]][mult,6]
==>36
mmadt> 6 => [is,[or,[a,int],[eq,1]]] => [mult,6]
==>36
mmadt> true => [is,[or,[a,int],[eq,1]]] => [mult,6]
mmadt> 'a' => [is,[a,int|1]] => [mult,5]
mmadt> 15  => [is,[a,int|1]] => [mult,5]
==>75
mmadt>

// a 'type' is an object whose structure is not fully defined and thus, applicable to many 'instances.'
// an 'instance' is an object that can only match/bind/define/etc. itself.

Thus, think of the LHS and RHS of => 'types/instances'

       'a' => [is,[a,int|1]] => [mult,5]
       
       
            str => int | 1 => int


mmadt> 15  => [a,int|1] => [mult,5]
java.lang.ClassCastException: class org.mmadt.machine.object.impl.atomic.TInt cannot be cast...


You are moving between sets of objects defined to arbitrary precision (advanced predicate/type structures requiring universal computing).

Here are some more examples:

  str|46               sum mixing 'types' and 'instances' in the specification
  str~a | 46~b         variant providing path labels for decision history
  str | [get,str~x]    instructions are objects and can be manipulated as such.
  
  
  [name:str&\^Dr.\~y       
   age:int&gt(0)&lt(150) <=[=mongo][get,'users'][is,[get,'name'][eq,y]][get,'age']]
  
         ^.____ an mm-ADT record with str-keys. 
             the name-value compiles to [a,str][regex,"\^Dr.\"][as,y]
             the age-value is [is,[a,int][and,[gt,0]][and,[lt,150]]] <= ... the mongo connection.
                 
                 
[=mongo] is a provider defined instruction.
MongoDB is represented in the mm-ADT data types. e.g., the root of the DB is some rec with keys being the name of 
                                                       collections and values being a stream of JSON documents 
                                                       (i.e. nested records)
                                                       
 The json{*} stream in the range of [is,[get,'name'][eq,y]] is large if y is left unbounded (as the token str).
 Without a bind (via the path ~[as] memories), a linear scan would be enacted.
 With a bind, [is,[get,name][eq,'marko']] is an "index lookup."
 There is a rewrite rule from [is,...] to index-hit. 
 
 Moving through aggregates (i.e. being in json{*} as oppposed to, e.g., json{235,694}) is how storage optimizations are modeled.
 The rewrite instructions at aggregates avoid e.g. [dedup] on unique data, [order] on ordered data, [count] when 
 databases cache such info, etc.
 
 This "graph of instructions" above the instance-level is known as The Reference Graph. References are another kind of datum.
 They sit between types and instances on a spectrum from "manifestable" to "unmanifestable."
 
      - Types: Loosely-specified structures with no <= can't be generated and thus, are descriptions as opposed to references.
      - References: Like types, their "predicate structure" matches many objects, but they have a "maps from" <=  operator (i.e. a stream!)
      - Instances: Structures whose "predicate" can match one and only one object -- itself.
      
      
// 'type'
mmadt> int => [a,int]
==>true
mmadt> int => [a,1]
==>false

// 'instance'
mmadt> 1 => [a,1]
==>true
mmadt> 1 => [a,int]
==>true

// 'reference'
mmadt> int{8} <= [start,3,6,7,8,4,6,78,8]
mmadt> int{8} => [start,3,6,7,8,4,6,78,8][gt,6][is,[eq,true]]
==>true
==>true
==>true
==>true
mmadt> int{8} <= [start,3,6,7,8,4,6,78,8] => [gt,6]                     // <= goes first, then => (left fold, then right fold)
==>bool{8} <= [start,3,6,7,8,4,6,78,8][gt,6]
mmadt> int{8} <= [start,3,6,7,8,4,6,78,8] => [is,[gt,6]]                // [is] is a filter instruction. they can radically alter object quantifiers.
==>int{0,8} <= [start,3,6,7,8,4,6,78,8][is,bool{0,8} <= [gt,6]]