Kata

Because only rows 1 & 2 are reported. Row 0 becomes [0,0,0] after 'S', and the instructions state that the smallest possible array is reported where any row or col has any element > 0.

While it could be added that only the four 'main' directions are possible, I think the other interpretation doesn't really make sense anyway. If 'NE' would make them move in a north easterly direction, then how would someone compute 'NNESEWWNW'?

There is a function whose parameter is misspelled

Which one? (btw, I didn't downvote you. You were at -1 when I saw your comment)

Just my own problem,Nothing to do with others. You don’t need to pay attention, I just express my feelings after finishing the kata.

Want Haskell?

Haskell translation

That one is good.

Approved 🖖

Hi Johan, can you post some barebones code of what you were trying to do? (with spoiler tag, of course)

Was the error you got: Must call super constructor in derived class before accessing 'this' or returning from derived constructor?

I can look into this and make some edits but some clues would be helpful. If you're on gitter you can DM me the code as well, which would be even better.

I could post the code, though I'd have to recreate it.

That was not the error. I'd have to recreate the exact error. It was weird - something about an @@iterator - as if a Blob was not an Array despite the inheritance.

I'm not asking to lift restrictions until my code would work. I am asking to mention the fact that there are restrictions at all.

I can just do a fork with the class Blobservation extends Array thing without the restrictions ( I hope. if the problem was the restrictions after all ). That will give you the code as well, but again, I'm not asking for lifting restrictions. I see the use of restrictions; I'm just wary of having to code with restrictions I don't know. ( I tend to use some valid features other people probably won't, and that might also be used for cheating. )

Let me get on that fork.

I forked my solution twice, once with massive breakage ( and the debug logging to show it ), and once without (?!?), because Blob.map(fn) barfs, but Array.from(blob,fn) works as expected.

In summary: it's not the anti-cheat. If anything, it's the argument format: I have terrible difficulty getting new Blob([...grid]) to work; based on separate testing, new Blob(...grid) would work just fine ( that is native new Array argument formatting ).

I wouldn't worry too much about dialing back the anti-cheat - but I still consider it an Issue to have it existing at all in secrecy.

Also, JS is weird.

Thanks for your input, Johan. I'll leave the issue up so nobody accidentally approves the kata. In the meantime, I'll look into making some tweaks that address the issue (without invalidating the already submitted solutions).

new Blob(grid).read("NES").read("WW").read("NWNSE") ?

That would be the functionally identical to read(read(read(grid,"NES"),"WW"),"NWNSE") though, and that can be reduced to ["NES","WW","NWNSE"].reduce(read,grid). But that's functional instead of OO, which is a valid choice not to make. ["NES","WW","NWNSE"].reduce( (grid,tilt) => grid.read(tilt) , grid ) would reduce the OO form. I like the functional form better, and it's shorter, but I'll grant most people would write the OO form.

The first line can evaluate to a Blob which can have a valueOf() that returns an Array. It might even be a Blob that inherits from an Array, effectively being an Array. ( I was trying to achieve this at first. ) It might even strictly be an Array if we define a mutating method Array.prototype.read. ( And that might go explicitly against your restrictions - though it might not either. )

Internal representation would not be fixed, neither with read(grid,tilt) nor with grid.read(tilt); you could use anything that takes your fancy. Even if you internally represent as an Array, but not as m x n, you could still use valueOf to externally present as an m x n Array.

In the case of class Blob extends Array you are simply optimising for this external presentation but in doing so fixing Array ( and m x n ) internally as well. A different Blob might not extend Array, or even its external representation, if that's not convenient, but this Blob can be written to this kata's specs.

It seems to boil down to a preference of functional vs. object-oriented. There doesn't seem to be a compelling reason against the latter approach, so I'll just leave it as is.

Aside from that, some minor additions have been made:

• "classes" and "object-oriented programming" tags added
• minor tweak to the random tests; now there are some cases where consecutive reads can occur before state is called again

@JohanWiltink In haskell, this typechecks

module BlobservationTwo where

data Blobservation -- not used, but required to exist

newBlobservation :: [[Int]] -> a
newBlobservation = undefined

read :: String -> a -> a
read = undefined

state :: a -> [[Int]]
state = undefined

Should there really be a typeclass in the initial code? Keeping in mind that a) it has no effect and can be deleted without any other changes as per above code b) haskell's typeclass isn't the same concept as javascript/whatever's class, sharing only the word "class". in terms of Rust, there are classes and traits, and a typeclass is a trait, not a class

There doesn't seem to be a compelling reason against the latter approach

It's wrapping things up in a class to no benefit. Three methods are asked for, but the kata only describes one significant action: (Grid, Direction) -> Grid

It's not object-oriented, it's wrapped up in do-nothingness.

The benefit is not changing the description.

Also, I don't speak Rust, and I agree with you guys.

Haven't you ever done useless things before, because your sensei, for no good reason, asked for it ?

Sorry, I'm talking about two things.

One of them is that I agree with you on that the class isn't doing anything in a language-agnostic sense.

The other is that haskell typeclasses are unrelated to classes. If we were to get closer to having a mutable blob with sequenced actions then that would be involving monads (writer monad?) But this isn't a 3-2kyu kata so that doesn't fit, it's already one of the hardest 5kyu katas. And also it would be super contrived since there's only one significant action, not three, but the other languages already have that problem.

I agree with you. Doc doesn't - see above.

And rankings can't be changed ( except when they can ).

@natan - This kata was written for languages that support the OO-paradigm. The Haskell translation was requested by the translator and it was accepted (as long as it adhered to the intent of the kata so as to maintain consistency). If you take issue with the implementation of the Haskell translation, then that's a conversation to be had with the translator. As for Rust, it uses structs, which would be the equivalent of a class in other languages.

@JohanWiltink - we've had an extensive conversation about this before where I commented:

First, I appreciate that you've written this translation in Haskell. While I don't want to diminish your efforts, I'm not completely confident about approving this. It feels a bit like trying to squeeze a square peg into a round hole in that the language may not be the right tool for the task. I also don't want the kata to be profoundly more difficult for someone coding in Haskell as opposed to an object-oriented language.

It sounds like @natan is talking about the very things I mentioned.

That's just what happens when you specify implementation instead of ( or in addition to ) behaviour. And I don't think that's a problem, actually.

It can be done differently in JavaScript as well, and the black boxes would also behave the same.

It's not so much hammering a round peg into a square hole as it is doing it with the back of an axe, or with the back of a screwdriver. But it will put the peg in the hole.

Okay. Thank you for being willing to respond to this and filling me in despite having already been there.

@docgunthrop if @johan is willing, could we drop the typeclass in the initial haskell code?

[haskell] may not be the right tool for the task.

The task isn't about calling convention! Is it? It's about blobs sloshing around. And it would still be the case that the user defines some object of undefined shape that has three operations.

I understand that you might have been reaching for something involving sequencing these operations, but that isn't what you caught when you closed your fist. There's an input operation, and an output operation, and a do-something operation. This is already how a function behaves. There's input, something happens, there's output. This is morally a single function. Both me and Johan implemented the input and output functions as identity functions (x) => x for this reason.

I'm harsh, I'm sorry. I do want this very nice puzzle to be lifted out to the front.

You could use something else as input and output functions, and have a different internal representation. Then you'd have all three operations actually doing work. The API is defined to have three operations. It could have specified some external format you didn't want as an internal format, and it's no more than a lucky coincidence it didn't.

If the input / output format had been specified as a separated or unseparated one-dimensional list ( and a separate width in case of no separators ), would you have worked with the external format as the internal format? I think you'd have felt fortunate to have the possibility to remodel your data.

You're comparing this to something likeVector.fromList, Vector.reverse, Vector.toList It fits the description without the typeclass. If it goes poof it looks a lot less scary and makes all sorts of sense. Test code stays 99% same (remove the import of Blobservation)

Yes? Yes.

Makes sense; I'll make some updates to the kata. Putting it back in Draft in the meantime.

There was a tiny bug in the reference solution but it should be fixed now.

Other changes:

• Description updated
• printState method renamed to state

Let me know your thoughts on the updates, thanks!

To address the following:

• you should revert the order of the sample tests: the integration test after the unit tests.

Within a common describe block, it blocks execute before describe blocks regardless of order. Changing the order in the sample tests might add confusion so it was left as is.

I'll probably update the sample tests since they don't affect the submitted solutions. Thanks for giving this one a shot!

EDIT: updated sample tests; now there are two separate describe blocks and now the unit tests precede the integration tests.

Ok, I'll take some time to check this. Thanks for mentioning this; temporarily reverting back to Draft for the moment.

Should be fixed now; can you give it another try?

Thanks for trying it out 🖖