Ad
  • Custom User Avatar

    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.

  • Custom User Avatar

    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.

  • Custom User Avatar

    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?

  • Custom User Avatar

    Please! don't use m and n that are not even defined in this kata (you have to go to the 3 kyu versions to understand what they mean). Use launches and eggs, instead.

    Even better: copy the whole description of the kata!

  • Custom User Avatar

    Haskell noob here -- I wrote up something that seems to typecheck and pass the sample tests, but it times out on submission with logs "Generating tests...". Is this necessarily an issue with my solution module? Otherwise, how should I interpret this -- should I be looking for a simpler proof?

  • Custom User Avatar
    "don't need to know neither"
    

    "neither" => "either"

    The description should clarify its comment on leading zeroes; should they be preserved in the transformation?

  • Custom User Avatar

    Hello,

    I try to solve this with Kotlin.
    But I got the feeling that the error message seems to bo wrong in the test cases.
    Here is an example:

    Input: 'run{->a}' expected:<[]> but was:<[Hugh?]>

    When I got the description correct the input is invalid so the answer should be Hugh? but the test case expects the empty string as answer.

    Is the test broken ? (Are some test broken ?)

    regards
    Kai

  • Custom User Avatar

    Typo in description: "reserse" should be "reverse".

  • Custom User Avatar

    It seems broken on Agda.
    If it's not, wider sample tests needed, because error messages are unhelpful and doesn't give any idea on which samples it's failing.

  • Custom User Avatar
  • Custom User Avatar
  • Custom User Avatar

    I had this test case: A < out > -> is this correct? According to the specification, I would doubt it. It seems to be a keyword, one that requires type behind it

    typeParam      ::= "*"
                     | "in " type
                     | "out " type
                     | type
    
  • Custom User Avatar

    For both Kotlin and Java, since userType can be just a name, having just functionType and userType should suffice in the definition of type

    type           ::= functionType
                     | name
                     | userType
    
  • Custom User Avatar

    In java section: params should be typeParams

    typeParams     ::= typeParam [ "," typeParams ]
    simpleUserType ::= name [ "<" params ">" ]
    
  • Custom User Avatar
  • Loading more items...