Updated sample test cases.

• makes initial solution compilable
• removes unnecessary comments
• adds more info to failure messages
• fixes order of actual and expected in assertions

This has no random tests, so I am rejecting (to make sure no one approves prematurely). You can fork this translation to add random tests.

If the type system will handle it, you can always write your let rec expressions in lambda syntax. If I can do it in LC, you can do it in Ocaml.

See https://en.wikipedia.org/wiki/Let_expression for how to rewrite let rec, and ping me on Discord ( in #lambda-calculus ) for how to do mutual recursion and Y*.

Note that I can't help you with the type system, and I know from Haskell recursive types can be a hassle. I might be able to do the type in Haskell, if that will help you do it in Ocaml ( it really helps here that LC is untyped ).

The let rec construct has some limitations, for example it is not possible to define the list of naturals like so :

let rec nats = 0 :: List.map ((+) 1) nats

The precise explanation of what is or is not acceptable as a right hand side is available in the OCaml manual.

Anyone know if applicative parsers are possible to do in Ocaml? (I know monadic ones can be done). I made an attempt at a translation, but Ocaml complains

Error: This kind of expression is not allowed as right-hand side of `let rec'

when I try to actually use the mutually recursive functions I wrote in my Haskell version (exprP, binP, etc). I'm not sure if I'm doing something wrong or if this is a limitation of the language, I would appreciate it if anyone can take a look at my translation.

My solution passes all the test cases but gives the error:

does not cheat
     scanl is not used

All of my answers were one line calls to scanl so I'm not sure what it's upset about. It possible to fix this one? It's a pretty fun problem.

The tests are correct.

populate() method gets called and right after that test checks print_state() and expects 12 elements instead of 8. How count of elements may change without calling the move(), or how it can increase even with move()?

Note the last few bullet points on the instructions:

This method may be called multiple times on the same class instance

If a new blob's position is already occupied by an existing blob, the two fuse into a single blob

In the test case generation 1 has already been populated. Notice that the state of the board just before populate(generation2) gets called.

blobs = Blobservation(10,8)
blobs.populate(generation1)
blobs.move()
pf(blobs,[[0,6,1],[1,1,1],[1,6,2],[2,1,5],[2,6,7],[4,2,6],[6,7,3],[7,1,2],[7,4,4],[7,7,1],[8,7,3]])
blobs.move(2)
pf(blobs,[[0,6,7],[1,5,3],[2,2,6],[4,1,6],[6,1,2],[6,4,4],[6,6,7]])
blobs.move(2)
pf(blobs,[[2,4,13],[3,3,3],[6,1,8],[6,2,4],[6,4,7]])
blobs.populate(generation2)

Relative to the blob (12 o clock is always up).

"every blob whose size is larger than the smallest blob size value will move to one of the 8 spaces immediately surrounding it in the direction of the nearest target blob with a lower relative size."

👍

Ok, I'll keep working on it. I'm up to 312.

It does seem strange that if the number of tests (and presumably the variables in each) are random that I'd successfully complete the same number most of the time though.

Edit: Nevermind, I figured it out. Good kata!

It looks like your algorithm needs to be optimized for speed. There are 600+ random tests.

EDIT: To be more precise, the number of total random tests will vary with each run. When running the tests a few times, the number of tests fell in the range 650 to 699.

Python 3. I tried changing my board from a dictionary to a list of lists instead but I still get the same result.

@scottmyran : what language is this for?