this should be 8kyu

I'm not sure that the kata's difficulty level really fits the problem.

Approved.

very easy

Crystal translation

Haskell fork that adjusts random test cases to filter out inputs that contain an operation that wraps the memory value

I overhauled Rust tests for this challenge, and I tried to get rid of the most obvious issues. Your solution passes too, after adding a small fix for one special requirement.

I am going to close this issue as resolved/obsolete, and feel free to raise a new one if you find any problems with the Rust translation.

character range for Julia is a-z, so it does contain invalid characters

Fixed for Java. Other affected languages are:

• C#,
• Groovy
• Not sure about Julia,
• Rust generates only 'a' fixed
• TypeScript

Fixed

In case of your solution, when you expand the "Stack trace" section, you can see something like this:

DeadFish.parse should work with fixed tests
  Test Failed
    c (of class java.lang.Character)
    Stack Trace
      scala.MatchError: c (of class java.lang.Character)
      	at DeadFish$.parse$$anonfun$1(solution.scala:12)
      	at DeadFish$.parse$$anonfun$adapted$1(solution.scala:14)
      	at scala.collection.StringOps$.foreach$extension(StringOps.scala:1039)
      	at DeadFish$.parse(solution.scala:14)
      	at DeadFishTest.testFun$proxy2$1$$anonfun$1(fixture.scala:27)
      [...snip...]

This basically means that your solution crashes due to non-exhaustive match. While I agree that the feedback is not great, it is not a problem with the kata itself, but more with the Scala reporter used by CW runner. You can see similar behavior in JUnit tests where user solution crashes with (for example) FormatException when parsing numbers: the failure message seems to be "hanging" without context, without info about the exception itself, and confusing users. I will close this ticket as not a kata issue, and I will think what can be done about the reporter.
The problem can be worked around by using noException should be thrownBy (https://www.scalatest.org/user_guide/using_matchers#expectedExceptions) (or assertDoesNotThrow in JUnit), but I think it's more of a workaround than actual requirement which should be imposed on authors of Scala translations.

Overflow is a separate matter, which also affects tests, but it is not related to your problem. It is also covered by already existing issue, which I will review and try to fix in other affected languages.

Without any information, we do not know either. Sorry.

Approved.

Done.

Approved.