update docs to use pod lang v1 (#268)

book/src/simpleexample.md

@@ -23,11 +23,11 @@ The reason is everything the circuit needs to verify that the statement is true.
 Example:
 
 ```
-STATEMENT1 = Equals(oldpod, "name", otherpod, "field")
+STATEMENT1 = Equals(oldpod["name"], otherpod["field"])
 
-STATEMENT2 = Equals(otherpod, "field", newpod, "result")
+STATEMENT2 = Equals(otherpod["field"], newpod["result"])
 
-STATEMENT3 = Equals(oldpod, "name", newpod, "result")
+STATEMENT3 = Equals(oldpod["name"], newpod["result"])
 ```
 
 The reasons in human-readable simplified format:
@@ -59,19 +59,19 @@ Equals(a, c)
 First, we need to decompose all the anchored keys as (key, origin) pairs.  This is the frontend description of the deduction rule.
 ```
 IF
-Equals(a_or, a_key, b_or, b_key)
+Equals(a_or[a_key], b_or[b_key)
 AND
-Equals(b_or, b_key, c_or, c_key)
+Equals(b_or[b_key], c_or[c_key])
 THEN
-Equals(a_or, a_key, c_or, c_key)
+Equals(a_or[a_key], c_or[c_key])
 ```
 
 In-circuit, all these identifiers are replaced with wildcards, which come in numerical order (because they will be used as array indices).  So the backend representation is:
 ```
 IF
-Equals( *1, *2, *3, *4 ) and Equals ( *3, *4, *5, *6 )
+Equals( ?1[?2], ?3[?4] ) and Equals ( ?3[?4], ?5[?6] )
 THEN
-Equals( *1, *2, *5, *6 )
+Equals( ?1[?2], ?5[?6] )
 ```
 
 
@@ -80,24 +80,24 @@ Equals( *1, *2, *5, *6 )
 - Repeat deduction rule
  ```
 IF
-Equals( *1, *2, *3, *4 ) and Equals ( *3, *4, *5, *6 )
+Equals( ?1[?2], ?3[?4] ) and Equals ( ?3[?4], ?5[?6] )
 THEN
-Equals( *1, *2, *5, *6 )
+Equals( ?1[?2], ?5[?6] )
 ```
 - Say what the wildcards are
 ```
-*1 -- oldpod
-*2 -- "name"
-*3 -- otherpod
+?1 -- oldpod
+?2 -- "name"
+?3 -- otherpod
 ...
 ```
 - Substitute the wildcards into the deduction rule
 ```
 IF
-Equals( oldpod, "name", ... ) ...
-Equals( otherpod, "value")
+Equals( oldpod["name"], ... ) ...
+Equals( otherpod["value"])
 THEN
-Equals( oldpod, "name", newpod, ... )
+Equals( oldpod["name"] newpod[...] )
 ...
 ```
 - Say where to find the previous statements (indices in the list), and check that they are above this one.
@@ -118,13 +118,13 @@ The wildcard system handles this very naturally, since origin ID and key are two
 ```
 eth_friend(src_or, src_key, dst_or, dst_key) = and<
     // there is an attestation pod that's a SIGNATURE POD
-    ValueOf(attestation_pod, "type", SIGNATURE)     
+    ValueOf(?attestation_pod["type"], SIGNATURE)     
     
     // the attestation pod is signed by (src_or, src_key)
-    Equal((attestation_pod, "signer"), (src_or, src_key))  
+    Equal(?attestation_pod["signer"], ?src_or[?src_key])  
 
     // that same attestation pod has an "attestation"
-    Equal((attestation_pod, "attestation"), (dst_or, dst_key))
+    Equal(?attestation_pod["attestation"], ?dst_or[?dst_key])
 >
 ```
 
@@ -132,9 +132,9 @@ In terms of anchored keys, it would be a little more complicated. five anchored
 ```
 AK1 = src
 AK2 = dst
-AK3 = (attestation_pod, "type")
-AK4 = (attestation_pod, "signer")
-AK5 = (attestation_pod, "attestation")
+AK3 = attestation_pod["type"]
+AK4 = attestation_pod["signer"]
+AK5 = attestation_pod["attestation"]
 ```
 
 and we need to force AK3, AK4, AK5 to come from the same origin.
@@ -142,14 +142,14 @@ and we need to force AK3, AK4, AK5 to come from the same origin.
 WILDCARD matching takes care of it.
 
 ```
-eth_friend(*1, *2, *3, *4) = and<
+eth_friend(?1, ?2, ?3, ?4) = and<
     // there is an attestation pod that's a SIGNATURE POD
-    ValueOf(*5, "type", SIGNATURE)     
+    ValueOf(?5["type"], SIGNATURE)     
     
-    // the attestation pod is signed by (src_or, src_key)
-    Equal((*5, "signer"), (*1, *2))  
+    // the attestation pod is signed by ?src_or[?src_key]
+    Equal(?5["signer"], ?1[?2])  
 
     // that same attestation pod has an "attestation"
-    Equal((*5, "attestation"), (*3, *4))
+    Equal(?5["attestation"], ?3[?4])
 >
 ```