←back to thread

99 points agnishom | 2 comments | | HN request time: 0s | source
Show context
codethief ◴[] No.44363911[source]
Reminds me of this classic: https://aphyr.com/posts/342-typing-the-technical-interview
replies(3): >>44364822 #>>44365630 #>>44366038 #
mightybyte ◴[] No.44366038[source]
As a professional haskeller, I feel it necessary to point out for people in this thread who are less exposed to Haskell and who may be Haskell-curious...this is not what real-world commercial Haskell code looks like. To use a C analogy, I'd say it's closer to IOCCC entries than Linux kernel code.
replies(2): >>44366389 #>>44368718 #
1. ralferoo ◴[] No.44366389[source]
Thanks for that. Having read the article, I was left with the overwhelming impression that I'd have solved it in a totally different way if I was trying in OCaml.

Briefly, I'd have started with an array which for each colour had an array containing the coordinate pairs for that colour. I'd probably then have sorted by length of each array. The state also has an empty array for the coordinates of each placed queen.

To solve, I'd take the head array as my candidates, and the remaining array of arrays as the next search space. For each candidate, I'd remove that coordinate and anything that was a queen move from it from the remaining arrays, and recursively solve that. If filtering out a candidate coordinate results in an empty list for any of the remaining arrays, you know that you've generated an invalid solution and can backtrack.

At no point would I actually have a representation of the board. That feels very imperative rather than functional to me.

To me, this solution immediately jumps out from the example - one of the queens in on a colour with only 1 square, so it HAS to be there. Placing that there immediately rules out one of the choices in both colours with 2 squares, so their positions are known immediately. From that point, the other 2 large regions have also been reduced to a single candidate each.

replies(1): >>44367047 #
2. mightybyte ◴[] No.44367047[source]
Yeah, comparing to how you'd solve this in any other mainstream language is really an apples-to-oranges comparison here because this is explicitly tackling the contrived problem of solving it at the type level rather than at the much more common value level. Very few languages in existence have the ability to do this kind of type-level computation. I'd say Haskell is really the only language that could conceivably be called "viable for mainstream use" that currently supports it, and even in Haskell's case the support is new, largely experimental, in a state of active research, and not well integrated with the ergonomics of the rest of the language.