Normalisation bug for `length` in nested query evaluator

[SimonJF]

(Prerequisite: #888 )

Trying to run:

fun tableLength3() server {
  query nested {
    length(for (x <-- factorials) [x]) == 3
  }
}

results in a normalisation error:

***: Error: "Assert_failure core/query/evalNestedQuery.ml:275:15" 

Looking closer, this is in Split.query, which seems to assume that outer queries must be a comprehension, conditional, concatenation, or singleton.

The "obvious" fix is to add an application case, but I'm not comfortable enough with the shredding algorithm to be confident in the absence of any knock-on effects.

[jamescheney]

I would leave it for now (or replace the assert failure with a more explicit "length not supported in shredded queries" error) since aggregations such as length were not considered in the normalization / shredding algorithm in the first place. Extending the theory to cover grouping/aggregation more systematically, and in combination with nested querying, is high on the agenda for the next few months.

[jamescheney]

Interestingly (at least to me) courtesy of @vcgalpin, some uses of length within nested queries do work:

var db = database "links";

var numbers = table "numbers" with (number: Int) from db;

var test_table = table "test_table" with (
                   id: Int,
                   integer: Int)
                 where id readonly from db;


fun countOcc (i) {
  query nested {
    length(
      for (x <-- test_table) 
        where (x.integer == i)
          [x]
    )
  }
}


links> countOcc(1);
Query.eval time: 1530
***: Error: "Assert_failure core/query/evalNestedQuery.ml:277:15" 

query nested {
  for (n <-- numbers)
    [(number=n.number,c=countOcc(n.number))]
}