What you quoted does not describe nameOrNumber. It's only the first bullet point for the three types of expressions, which also includes numbers.

We have three kinds of basic expressions:

• names, like abc, ABC, run, a1, beginning with _/letters and followed by _/letters/numbers
• numbers, like 123, 02333, 66666 (may have leading zeroes)
• lambda expressions, like { a -> a }, { a, b -> a b }(source), (a){a;}, (a,b){a;b;}(target)

Additionally, the BNF for both source and target do not specify nameOrNumber, and per the grammar described, something like {3,x->y} is a valid lambda function as it matches the following pattern: "{" <nameOrNumber> "," <nameOrNumber> "->" <nameOrNumber> "}"

And as another point, the description specifically states that lambda expression parameters are names/numbers:

Lambda expressions consist of two parts:

• parameters, they're just names/numbers
• statements, a list of names/numbers, seperated by whitespaces in source language, by ; in target language.

nameOrNumber is specified as follows:

names, like abc, ABC, run, a1, beginning with _/letters and followed by _/letters/numbers

So your assumption seems incorrect to me.

In the process of adding random tests to Haskell (fork here), I found that there are two types of valid inputs that aren't covered by the existing tests:

• Lambda expressions with numbers as parameters (such as "{3->a}()")
  • Intuitively, I wouldn't expect numbers to be valid lambda parameters, but that's how it's described in the grammar for both the source and target languages
• Expressions that do not invoke a function call (such as "fun", "34", or "{a->a}")

These cases are included in this new fork. The author's solution had to be updated to pass these tests, and it's likely that many other solutions will be invalidated as well.

The published Haskell translation has this as an edge case.

I know it's been a while since this was published, but could you please check the latest issue about this? :P

It would be good to have in the description the boundaries for the input. For instance, knowing whether the maximum number of bytes ever exceeds 255 would change my approach to the problem.

Also, I personally believe that "Mention, don't care about" isn't very clear. I'm not sure whether those cases are present in the input and I have to disconsider them or if they aren't present at all.

well, from the docs (https://kotlinlang.org/docs/native-objc-interop.html#initializers) ..

because Kotlin has no concept of extension constructors.

so what is this kata about

any further hints? I got rid of the division by modular inverse but still too slow for random test

This kata was decided to stay.

Good Kata! Thanks to author!!!

To answer the question, not quite. If you had two eggs and 14 tries, and observed the first egg break on the Nth try, you then have one egg and 14-N tries remaining. In other words, the tries are cumulative. Notice therefore that increasing n beyond m has no effect, since you can use up at most m eggs no matter your strategy.

Good kata, I learned something new today.

Nice kata for C++ training on parsers, error handling, and such.
With modern C++17 (variants and visitors, exception handling, string_view, and such) quite straightforward to
solve : just parse the way you describe the langage and... debug for errors.
Thus ... overranked IMHO

Note : would have needed a proper C++ translation (passing const std::string& and returning a std::string), pissed with those const char returning functions...*

Omg this is so hardcore.
I needed to dig into really advanced math hacks.
Finally i discovered good pure- math move to calculate this significally less then limited time - below 4 seconds, in Python and i am finally satisfied :D

I don't think Cubical.HITs.HitInt exists in the cubical library anymore. It seems to have been replaced with QuoInt. This makes it hard to complete this kata. Anyway this can be updated?