prevent unnecessary recursive applications of _determineActualTypes

[davidchambers]

Commit message (modified to take advantage of GitHub and Markdown features):

This commit fixes an error in #78 which resulted in unnecessary recursive applications of _determineActualTypes when determining the types of a collection whose elements are members of a unary type.

For a given collection c whose elements are members of some unary type, the complexity of the faulty algorithm is O(tⁿ), where t is the number of types of which all the inner values of c's elements are members, and n is the number of elements of c.

The actual types of the first element of c should be determined, once, then refined by interrogating the remaining elements of c. The faulty algorithm, though, would determine the actual types of elements of c t¹ + t² + t³ + … + tⁿ times. For example:

c = [[1], [2], [3], [4], [5]]
t = 3 (Number, ValidNumber, FiniteNumber)
n = 5

3^1 + 3^2 + 3^3 + 3^4 + 3^5

The superfluous recursion produced duplicate results, prompting the deduplication added in #159.

This commit prevents superfluous recursion, obviating the need for deduplication. The complexity is now O(tn), a dramatic improvement!

In order to visualize the faulty algorithm one should first apply this patch on master:

--- a/index.js
+++ b/index.js
@@ -918,12 +918,23 @@
     }
   }
 
+  var __sentinel = {};
+  var __lastSeen = __sentinel;
+
   //  _determineActualTypes :: ... -> Array Type
   function _determineActualTypes(
     env,            // :: Array Type
     seen,           // :: Array Object
     values          // :: Array Any
   ) {
+    if (__lastSeen === __sentinel) {
+      process.stdout.write(Z.toString(values) + ' ');
+    } else if (!Z.equals(values, __lastSeen)) {
+      process.stdout.write('\n' + Z.toString(values) + ' ');
+    }
+    process.stdout.write('I');
+    __lastSeen = values;
+
     var recur = _determineActualTypes;
 
     function refine(types, value) {

One can then run the following commands to see how t affects the number of operations:

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I
[2] I
[3] I
[4] I
[5] I

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number, $.ValidNumber]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I
[2] II
[3] IIII
[4] IIIIIIII
[5] IIIIIIIIIIIIIIII

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number, $.ValidNumber, $.FiniteNumber]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I
[2] III
[3] IIIIIIIII
[4] IIIIIIIIIIIIIIIIIIIIIIIIIII
[5] IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII

The results are very different on davidchambers/perf:

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number, $.ValidNumber]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I

$ node -e 'const $ = require ("./"); $.create ({checkTypes: true, env: [$.Array ($.Unknown), $.Number, $.ValidNumber, $.FiniteNumber]}) ("thunk") ({}) ([$.TypeVariable ("a")]) (() => [[1], [2], [3], [4], [5]]) ()' && echo
[[1], [2], [3], [4], [5]] I
[1] I

This fix will dramatically reduce the performance impact of type checking, rendering sanctuary-js/sanctuary#464 unnecessary. :)

[gabejohnson]

These numbers are impressive David!

Have you given any thought to putting some benchmarks in place? It would be nice to avoid performance regressions in the future.

[Avaq]

Excellent!

[davidchambers]

Have you given any thought to putting some benchmarks in place? It would be nice to avoid performance regressions in the future.

Benchmarks would be very nice indeed! I'll tie up the loose ends that are blocking sanctuary-js/sanctuary-benchmark#1 in the near future. :)