quant_foreach -> do; quant_check -> check

Author: garfix

doc/manual/knowledge-engineer/creating-a-grammar.md

@@ -42,7 +42,7 @@ I don't think I found the ultimate way to represent questions, but what I'd like
 
 and then refine the changing part in a separate rule:
 
-    { rule: do_clause(P1) -> np(E1) tv(P1, E1, E2) np(E2),                              sense: quant_check($np1, quant_check( $np2, $tv)) }
+    { rule: do_clause(P1) -> np(E1) tv(P1, E1, E2) np(E2),                              sense: check($np1, check( $np2, $tv)) }
 
 The first rule states that these type of questions start with "do" and that they are yes/no questions, which means that their answer is a simple yes or no. The `intent(yes_no)` in the sense of the rule is a kind of tag that is used by the solution to recognize the type of sentence.
 
@@ -62,7 +62,7 @@ A declarative sentence states something to be the case. The aim of the sentence
 
 Let's start with simple declarative sentences. This one handles sentences like: "all red blocks are mine"
 
-    { rule: declarative(P1) -> np(E1) copula(_) np(E2),         sense: assert( own(A, B) :- quant_check($np1, quant_check($np2, equals(A, E2) equals(B, E1)))) }        
+    { rule: declarative(P1) -> np(E1) copula(_) np(E2),         sense: assert( own(A, B) :- check($np1, check($np2, equals(A, E2) equals(B, E1)))) }        
 
 A `copula` is a verb like "is" and "are" when it has no meaning of its own in the sentence. In the sense you can see the `assert` relation whose single argument is a rule. When this declarative is executed, the `assert` adds a rule to a rule base (the first rule base known to the system). 
 
@@ -83,11 +83,11 @@ This is how to implement "all red blocks are mine, but the blocks in the box are
 
     { rule: default_rule(P1) -> np(E1) tv(P1, A, B) np(E2),                           sense: assert(
                                                                                         $tv :-
-                                                                                        quant_check($np, quant_check($np2, equals(A, E1) equals(B, E2) not( -$tv )))) }
+                                                                                        check($np, check($np2, equals(A, E1) equals(B, E2) not( -$tv )))) }
 
     { rule: assertion(P1) -> np(E1) dont(_) tv(P1, A, B) np(E2),                      sense: assert(
                                                                                         -$tv :-
-                                                                                        quant_check($np1, quant_check($np2, equals(A, E1) equals(B, E2))) }
+                                                                                        check($np1, check($np2, equals(A, E1) equals(B, E2))) }
 
 These last rules form the default rule and the exception. They are posed in a general way that allows for multiple application. The first says "NP verb NP", which handles clauses like "I like ice" and "you own the table". Note the sense: the head is `$tv`, which is the meaning of the second child in the rule (`tv(P1, A, B)`), and this head reoccurs later on in rule, in the form of  `not( -$tv )`. The meaning here is "I own all red blocks except for the ones that I don't own".
 
@@ -156,7 +156,7 @@ At the moment the `proper_noun_group` is processed, the parser has received top-
 
 Let's have an example:
 
-    { rule: nbar(E1) -> 'daughter' 'of' np(E2),                                sense: quant_check($np, has_daughter(E2, E1)) }
+    { rule: nbar(E1) -> 'daughter' 'of' np(E2),                                sense: check($np, has_daughter(E2, E1)) }
 
 Here `np(E2)` will be rewritten to the name "Charles Babbage". The parser also sees that E2 is the first argument of the relation `has_daughter(E2, E1)`. And you can tell the system that the first argument of this relation is a person, by adding this line to the file "argument-sort.relation":
 
@@ -183,7 +183,7 @@ There are transitive verbs (`tv`) and intransitive verbs (`iv`). Transitive verb
 
 Here's a simple rewrite for a transitive verb phrase:
 
-    { rule: vp(P1, E1) -> marry(P1) np(E2),                                sense: quant_check($np, marry(P1, E1, E2)) }
+    { rule: vp(P1, E1) -> marry(P1) np(E2),                                sense: check($np, marry(P1, E1, E2)) }
 
 The `find` combines the `quant` or `quant`s with the sense of the verb. `find` iterates over all combinations of values for the quants.
 
@@ -221,13 +221,13 @@ An attributive adjective preceeds a noun phrase. There can be multiple adjective
 Phrases like "is taller than" are also adjective, but in a predicative way.
 
     { rule: relative_clause(E1) -> 'which' copula(C1) adjp(E1) }
-    { rule: adjp(E1) -> 'taller' 'than' np(E2),                            sense: quant_check($np, taller(E1, E2)) }
+    { rule: adjp(E1) -> 'taller' 'than' np(E2),                            sense: check($np, taller(E1, E2)) }
 
 ## Prepositional phrases
 
 These phrases denote a relation between two noun phrases. Here's the rule for the preposition "in".
 
-    { rule: pp(E1) -> 'in' np(E2),                                         sense: quant_check($np, contain(_, E2, E1)) }
+    { rule: pp(E1) -> 'in' np(E2),                                         sense: check($np, contain(_, E2, E1)) }
 
 ## Numbers
 

doc/manual/knowledge-engineer/function-reference/grammar.md

@@ -13,26 +13,29 @@ This relation is used by solutions to recognize types of problems.
 
 An intent function has no effect; it always succeeds.    
 
-## Quant foreach
+## Do
 
-Find all entities specified by a `quant` (minimally), assign each of them in turn to a variable and execute `Scope`.
+Finds the entities specified by a `quant`, assign each of them in turn to a variable and execute `Scope`.
 
-Fails as soon as a scope returns no results. 
+Does not continue to find entities after the quantifier has succeeded.
+Fails if the number of entities that pass `Scope` is **less than** the same as specified by the quantifier of `Quant`.
 
-    go:quant_foreach(Quant ..., Scope)
+    go:do(Quant ..., Scope)
 
 * `Quant`: a quant
 * `Scope`: a relation set    
 
 Check [quantification](quantification.md) for more information.
 
-## Quant check
+## Check
 
-Find all entities specified by `Quants`, check if the number of entities that pass `Scope` is the same as specified by the quantifier of `Quant`. 
+Find all entities specified by `Quant`.
 
-    go:quant_check(Quants, Scope)
+Fails if the number of entities that pass `Scope` is not the same as specified by the quantifier of `Quant`. 
+
+    go:check(Quant, Scope)
 
-* `Quants`: one or more quants
+* `Quant`: a quant
 * `Scope`: a relation set      
 
 Check [quantification](quantification.md) for more information.

doc/manual/knowledge-engineer/modules-namespaces.md

@@ -56,6 +56,6 @@ These aliases are called `module aliases`. They are used by NLI-GO to locate rel
 
 Built-in predicates are always prefixed by the system-alias `go`. For example:
 
-    go:quant_check($np, dom:has_father(E2, E1))
+    go:check($np, dom:has_father(E2, E1))
 
 

doc/manual/knowledge-engineer/quantification.md

@@ -62,22 +62,22 @@ Here is the typical case for the `qp`. Note that the `quantifier` relation is fo
 
 The quant is only useful when combined with a parent relation (typically a verb). You need to specify explicity that the quant is used. If there is more than one quant, the order of the quants can be given. An example:
 
-    { rule: np_comp4(P1) -> np(E1) marry(P1) 'to' np(E2),                    sense: quant_check($np1, quant_check($np2, marry(P1, E1, E2))) }
+    { rule: np_comp4(P1) -> np(E1) marry(P1) 'to' np(E2),                    sense: check($np1, check($np2, marry(P1, E1, E2))) }
 
 Imagine the sentence: "Did all these men marry two women?". Resolving this question means going through all the men, one-by-one, and for each of them counting the women that were married to them. If one of them married only one woman, the answer is no.     
 
-`quant_check` says: apply the quants from the right-hand positions 1 (`$np1`), which is the sense of the `np(E1)` and 4 (`$np2`) and use them in that order. When the sense is built, the result looks like this:
+`check` says: apply the quants from the right-hand positions 1 (`$np1`), which is the sense of the `np(E1)` and 4 (`$np2`) and use them in that order. When the sense is built, the result looks like this:
 
-    quant_check(
+    check(
         quant(Q1, E1, ...), 
         marry(P1, E1, E2)
     )     
 
-`quant_check` has a set of quantifiers, and a _scope_ that consists of zero or more relations (`marry(P1, E1, E2)`).
+`check` has a set of quantifiers, and a _scope_ that consists of zero or more relations (`marry(P1, E1, E2)`).
 
 In this example the quant for E1 precedes that of E2, but the order does not need to match the order of the variables in the scope.
 
-It is important to understand the way `quant_check` is evaluated. I will sketch the process here briefly. Note that the quants are nested, and that the inner loop uses a single value from the range of the outer quant, and goes through all range values of the inner loop.
+It is important to understand the way `check` is evaluated. I will sketch the process here briefly. Note that the quants are nested, and that the inner loop uses a single value from the range of the outer quant, and goes through all range values of the inner loop.
 
     b1 = []binding
     foreach E1-range-set as E1 in outer range {
@@ -95,7 +95,7 @@ This is the process for 2 quants. The number of quants is often 1, and possibly
 
 ## Quant foreach
 
-The function `quant_foreach` is exactly like find, with one important distinction: `do` checks the quantifier _during_ the loop as well.
+The function `do` is exactly like find, with one important distinction: `do` checks the quantifier _during_ the loop as well.
 
     foreach E2-range-set as E2 in inner range {
         execute scope, bound with single E1 and E2, and add binding to b2
@@ -106,9 +106,9 @@ This relation is needed for different kinds of relations: imperative ones, like
 
 Imagine now this sentence: "pick up two blocks". 
 
-Handling this question with `quant_check` amounts to picking up all blocks and then checking if there were two that were picked up. This is clearly nonsense. `quant_foreach` goes through all blocks, and attempts to pick them up. As soon as the quantifier `2` matches, it stops.
+Handling this question with `check` amounts to picking up all blocks and then checking if there were two that were picked up. This is clearly nonsense. `do` goes through all blocks, and attempts to pick them up. As soon as the quantifier `2` matches, it stops.
 
-The difference between `quant_check` and `quant_foreach` is that `quant_foreach` stops when it has enough, while `quant_check` continues. Use `quant_check` with interrogative relations and `quant_foreach` with imperative relations. 
+The difference between `check` and `do` is that `do` stops when it has enough, while `check` continues. Use `check` with interrogative relations and `do` with imperative relations. 
 
 ## Unquantified nouns
 

doc/manual/system-developer/processing.md

@@ -68,7 +68,7 @@ To use the parser, you need to define a grammar.
 
 Each grammar entry contains a rule and, optionally, a sense. The rule is the syntactic part, but extended with entity variables. The sense consists of the relations that are created when parsing the sentence. The entity variables of the syntax reappear in the relations. Let me give you an example of how this works. When the following rewrite rule has been completed (example clause: John could marry Elsa)
 
-    { rule: np_comp2(E1) -> child(E1) have(_) np(E2),                       sense: go:quant_check($np, dom:have_child(E2, E1)) }
+    { rule: np_comp2(E1) -> child(E1) have(_) np(E2),                       sense: go:check($np, dom:have_child(E2, E1)) }
 
     { rule: interrogative(P1) -> 'how' 'many' np_comp2(E1),                 sense: go:intent(how_many, E1) }
 
@@ -97,7 +97,7 @@ The example sentence (from Tokenizer paragraph) yields the following parse tree:
 When the whole tree is parsed all relations will be connected in a relational model. I just call this a relation set.
  Here's the relation set for our sample sentence:
 
-    go_quant_check(go_quant(go_quantifier(R9, R10, go_equals(R9, R10)), E8, none), dom_have_child(E8, E7)) go_intent(how_many, E7) go_intent(question)
+    go_check(go_quant(go_quantifier(R9, R10, go_equals(R9, R10)), E8, none), dom_have_child(E8, E7)) go_intent(how_many, E7) go_intent(question)
 
 ### Answerer
 

doc/remarks.md

@@ -1,3 +1,10 @@
+## 2022-10-31
+
+Replaced `go:quant_foreach()` by `go:do()`.
+Replaced `go:quant_check()` by `go:check()`.
+
+These are high frequent constructs and should have short and clear names.
+
 ## 2022-10-30
 
 Currently deactivating the `go:has_sort()` built-in predicate, because it just complicated things.

doc/todo.md

@@ -38,7 +38,6 @@ If the next sentence is "The waiter showed us our seat.", "the waiter" refers to
 
 Make it consistent, complete, robust, etc. Have it conform existing paradigms.
 
-- turn the "JSON" datatype into a "binary" datatype
 - maybe remove `result` from `responses` in the intent; it is not used now
 - I must implement all entities with atoms. Currently they are variables, but it means that variables are used as values, and this is clumsy. Then there must be a mapping from these atoms to database ids.
 - typed arguments

lib/knowledge/function/SystemSolverFunctionBase.go

@@ -32,8 +32,8 @@ func (base *SystemSolverFunctionBase) GetFunctions() map[string]api.SolverFuncti
 		mentalese.PredicateEventReference: base.eventReference,
 
 		// quant
-		mentalese.PredicateQuantCheck:       base.quantCheck,
-		mentalese.PredicateQuantForeach:     base.quantForeach,
+		mentalese.PredicateCheck:            base.quantCheck,
+		mentalese.PredicateDo:               base.quantForeach,
 		mentalese.PredicateQuantOrderedList: base.quantOrderedList,
 
 		// control

lib/mentalese/Relation.go

@@ -26,8 +26,8 @@ const SortEntity = "entity"
 const SortEvent = "event"
 
 const PredicateCanned = "go_canned"
-const PredicateQuantCheck = "go_quant_check"
-const PredicateQuantForeach = "go_quant_foreach"
+const PredicateCheck = "go_check"
+const PredicateDo = "go_do"
 const PredicateQuantOrderedList = "go_quant_ordered_list"
 const PredicateQuant = "go_quant"
 const PredicateQuantifier = "go_quantifier"