Voile... your solution 😭😆

I'd read through The Art of Prolog in the previous month, so definitely some arrogance came into play!

Lovely kata! 😁

I keep getting one test wrong, whenever I attempt:

Test Failed
expected: (= (count subsets) (Math/round (Math/pow 2 4)))
  actual: (not (= 15 16))

Of course, because the tests are so opaque, I have no idea what I've got wrong. Well, actually, I can guess what the test might have been, but... for a set of 4 distinct items (since the other tests don't consider the empty set a subset of other sets, strangely enough) the total number of subsets should be 15, rather than 16—so either it's something else, or I'm not the one to have made a mistake!

Okay, it's obvious enough what I've done wrong... would be nice to have some less opaque testing, still, though!

OK, done. It's less "perfect" that I'd have wanted to do it, but far enough, I guess.

Kata totally revamped... (description, specs, tests)

trying to implement random ast tests, actually. Not in a hurry ;)

@Blind4Basics I think you've waited enough, eh? ;)

yes I know. But I don't wanna do it in a hurry because I'll actually completely change the requirements doing the update, so I'll still wait a bit (the context will be the same, but the actual task will be way more difficult than it is right now)

The author is inactive - last seen June - you might update it yourself.

Hi,

Seems you forgot about your kata... I didn't. ;p

I managed to build a complete solution/test suite with compile time errors only, keeping the show method to check the actual correctness of the results (and I suppressed main/putStrLn).
The expected errors are:

• ArgumentError for mismatched number of arguments
• TypeError for any mismatched type anywhere (inputs and/or output)

I'll let you some more time, but if I don't get any feedback, I'll eventually update the kata with that (and so, rewrite the whole description too... xs )

cheers

So, what's up there? x)

(If you don't do anything, you'll end up some day discovering an update of your kata suiting my mind... ;o )

btw, I thought about the strategy of "error at compile time": That could spare you the random tests, because as long as an user doesn't have a working solution, he won't be able to abuse anything since his code won't even be executed. That is, ofc, if you ask for an identifiable exception (meaning: one that would be raised specifically by the user and that couldn't occur automatically with a wrong code)

(edit: worst case, adding some randomized tests involving compile time exceptions could be enough to forbid a cheating completion)

up again! ;o

still procrastinating? ;)

I updated the fork: I realized I forgot one kind of check (number of arguments in a function call). Tho, here the choice of what is done at compile or runtime becomes critical, to keep the whole task consistent. for instance, some checks make perfect sense at compile time, but going that way it becomes a bit weird to make the check of the type of the inputs at runtime only. For the check of the output of the functions, it still stays the easiest way to implement the tests/kata, tho.

You'll have some critical choices to do... ;)

there's no hurry. ;)

cheers