The last code block has this spec. Closing.

fixed here

approved by someone

JS Fork to address this suggestion. Also fixes description, increases documentation, and adds very minor test enhancements

The anticheat tests are incorrect and fail the reference solution too.

1. The isUniversal anticheat: This line in generate

expect(your_result.isUniversal(), "isUniversal").to.equal(false)

Will incorrectly cause unconditional failure for some test cases. For example, if your random tests run new FunctionalSet([D]).difference(new FunctionalSet([D]).difference(new FunctionalSet([C]))).not() (which should, in fact, be universal).

2. For the anticheats, the variables in the tests are scoped in a problematic way (namely your_result, my_result and _it). By scoping them outside the test loop, every single it block will be reading and writing to/from the same references. This is a problem because Chai sets up the fixtures way before any of the it blocks are run. Before any it is run, these variables would have had their values overwritten on each loop, until they settle on the values from the final iteration. So the end result is basically your_result, my_result and _it having the same values on each run. Since the titles of the it blocks are also precomputed, they do NOT match what is really being tested.

3. The anti cheating memoization test: The functional set argument returns a string instead of a boolean. Discussed in the issue below mine by Invariance.

This. It's driving me nuts

Interesting Kata for exploring generators!

Took 2 weeks to solve, but I had a lot of fun, and learned a lot on the way!!

Something is wrong with the Duplication exception tests

TSError: ⨯ Unable to compile TypeScript:
test.ts:608:16 - error TS18046: 'e' is of type 'unknown'.

608         expect(e.message).to.equal('Duplicate ' + duplicate);

I did comment it out from my sample tests, and it allowed my solution to pass all tests.

I also, tried other users solutions, and they do not pass this test case as well.

Python new test frameworks are required.

So calling two separate where-filters is a logical AND, while combining two where-filters in one where-call is an OR?

// SELECT studentName, teacherName FROM teachers, students WHERE teachers.teacherId = students.tutor AND tutor = 1
query().select(student).from(teachers, students).where(teacherJoin).where(tutor1).execute(); //[{"studentName":"Michael","teacherName":"Peter"}] <- AND filter
// SELECT * FROM number WHERE number < 3 OR number > 4
query().select().from(numbers).where(lessThan3, greaterThan4).execute(); //[1, 2, 5, 7] <- OR filter

Missing mutable test cases for takeWhile.

var list = ArrayComprehension({
  generator: "1..",
  mutable: true
});

Test.assertSimilar(list.takeWhile(n => n < 5).value(), [1,2,3,4]);
Test.assertSimilar(list.takeWhile(n => n > 4).take(4).value(), [5,6,7,8]);

I would of course love to solve in python as well, however it seems to me that time has passed. This kata is practically 10 years old and now IMHO, it is not 1kuy. Maybe you should just do something based on this task, but heavily refined (I mean a completely new publication)? For example, make it a performance task, add: JOIN, LEFT JOIN, RIGHT JOIN, DISTINCT, CASE, EXISTS.... These are just as examples of what could be implemented and improve this kata.

By the way as a performance option, if there will be large data volumes and different sized tables, the right JOIN will make a difference. If you do it nicely and add significant differences from this kata, I think it would be a great new kata.

p.s. I wonder if anyone has responded on Discord though? What kind of response did you get?

Nice kata, very theoretic mathematically speaking.