README.md

go/src/miller/dsl/cst/README.md

@@ -17,6 +17,6 @@ As a result, throughout the code, there are error checks which may seem redundan
 
 During CST build from an AST, one starts from the AST root and walks down through the nodes of the AST. Within a caller method, there is an if/else or switch statement on the AST node type. (Example: is this a leaf node, like the string literal `"abcd"`, int literal `3`, field-name `$x`? Or a binary operator like `+`, or function call like `cos`?).
 
-Different builder methods are invoked for leaves, operators, etc. There is also, redundantly, a precondition assertion within each builder method: the leaf-builder method checks to make sure it's given an AST leaf node to build from; the operator-builder method checks to make sure it's given an AST operator node to build from; etc. The latter return Go `error` in case there is something new in the caller which has not yet been implemented in the callee.
+Different builder methods are invoked for leaves, operators, etc. There is also, redundantly, a precondition assertion within each builder method: the leaf-builder method checks to make sure it's given an AST leaf node to build from; the operator-builder method checks to make sure it's given an AST operator node to build from; etc. The caller and the callee are doing the same kinds of check, which might seem redundant. The callees return Go `error` in case there is something new in the caller which has not yet been implemented in the callee.
 
 This is all done to make development more happy: when you see things like `CST build: AST unary operator node unhandled.` you can check the code here and see what you need to do next to continue development.