That's certainly a description, but I'm not sure it's terribly useful for anyone who doesn't already know what confluence means in the context of a rewriting system.
If that work is too dense, all you need to know is the first paragraph. If that's all greek to you, it can be expanded as follows: Suppose you have a program e and an interpreter that executes e by applying a big set of rules that rewrite e until e becomes a value (such as a number, string, function, etc.).
So, for example, (function add(x) { x+x }; add(5)) -> 5+5 -> 6+4 -> 7+3 -> ... -> 10.
Here, "->" is thedefined by a big set of rules that basically pattern match on the syntax of the left-hand term and produce a corresponding right-hand term. So, for example, we have rules like:
(function F(x) { B[x] }; F(y) -> B[y]
and
n+m -> (increment of n) + (decrement of m)
and
n+0 -> n
where n,m are defined to be non-negative natural numbers.
Your interpreter is just a big set of these sorts of rewriting rules, and there's no "ordering" on the rules. Any rule that is applicable to the left-hand side could be used at any point where it's applicable.
Imagine, now, that you define your rewrite rules and then notice that at some points more than one rule might be applicable to the left hand side!
That could be bad if a single program could compute different values depending on which rule was chosen!
In general: Suppose there are some rewrite rules such that that e -> ... -> e1. (Which we sometimes write as e ->^* e1 for readability.) Suppose there are also some rules such that e -> ... -> e2, where e1 and e2 are different and might not be values (ie there's still more rules applicable to e2 and e3).
Your system is confluent -- i.e., not bad in the above sense -- if whenever the above happens there are also some rules such that e1 -> ... -> e3 and e2 -> ... -> e3. Then you know "there are many possible executions of the interpreter but at the end of the day the interpreter always spits out the same value"
For the casual programmer who's seen a lambda calculus at some point and is interested in understanding confluence in some detail, I recommend https://www.cs.cornell.edu/~kozen/Papers/ChurchRosser.pdf
If that work is too dense, all you need to know is the first paragraph. If that's all greek to you, it can be expanded as follows: Suppose you have a program e and an interpreter that executes e by applying a big set of rules that rewrite e until e becomes a value (such as a number, string, function, etc.).
So, for example, (function add(x) { x+x }; add(5)) -> 5+5 -> 6+4 -> 7+3 -> ... -> 10.
Here, "->" is thedefined by a big set of rules that basically pattern match on the syntax of the left-hand term and produce a corresponding right-hand term. So, for example, we have rules like:
(function F(x) { B[x] }; F(y) -> B[y]
and
n+m -> (increment of n) + (decrement of m)
and
n+0 -> n
where n,m are defined to be non-negative natural numbers.
Your interpreter is just a big set of these sorts of rewriting rules, and there's no "ordering" on the rules. Any rule that is applicable to the left-hand side could be used at any point where it's applicable.
Imagine, now, that you define your rewrite rules and then notice that at some points more than one rule might be applicable to the left hand side!
That could be bad if a single program could compute different values depending on which rule was chosen!
In general: Suppose there are some rewrite rules such that that e -> ... -> e1. (Which we sometimes write as e ->^* e1 for readability.) Suppose there are also some rules such that e -> ... -> e2, where e1 and e2 are different and might not be values (ie there's still more rules applicable to e2 and e3).
Your system is confluent -- i.e., not bad in the above sense -- if whenever the above happens there are also some rules such that e1 -> ... -> e3 and e2 -> ... -> e3. Then you know "there are many possible executions of the interpreter but at the end of the day the interpreter always spits out the same value"