dominoes: ask for chain rather than canChain OR modify README to ask for canChain

[petertseng]

There are two possible ways to interpret the dominoes problem, as the canonical data tells us.

1. Only ask for canChain, a boolean telling us whether the given dominoes can be chained. The tests only need to check whether the boolean matches the expectation.
2. Ask for chain, which will be (I assume for F#) Some of a valid chain if one exists, or None if one does not. The tests would need to check the various properties noted in the canonical data

This track asks for canChain only. I assumed this was an intentional decision, so I did not question it. But Erik asked me to file an issue. So y'all can reopen the issue in case y'all want to ask for chain.

[ErikSchierboom]

@robkeim How do you feel about this?

[petertseng]

Oh, for the record, I find it highly unlikely that a student implementation will falsely pass the tests even if the tests only look for true/false, so I don't think this is very urgent. I predict that students will still actually attempt to find a chain (and if they don't, they're the ones missing out!).

If my prediction is correct, then I think the main advantage of implementing chain is simply a little bit of student peace-of-mind that the chain found by the code is correct. But most of that peace-of-mind is probably already had by canChain?

And if chain gets implemented, the disadvantage tests will get more complex, so y'all have to be prepared for the maintainership of that extra test code.

Current implementors that use boolean only:

• C#
• F#
• Swift

Current implementors that use domino list option (or similar)

• Haskell
• OCaml
• Ruby
• Rust
• Scala

[robkeim]

disclaimer: I haven't implemented this exercise myself yet

If my prediction is correct, then I think the main advantage of implementing chain is simply a little bit of student peace-of-mind that the chain found by the code is correct. But most of that peace-of-mind is probably already had by canChain?

I would definitely feel more confident my solution worked correctly if chain were validated as opposed to canChain.

And if chain gets implemented, the disadvantage tests will get more complex, so y'all have to be prepared for the maintainership of that extra test code.

I had a look at the other tracks that implemented chain (I updated @petertseng's post above to include the links) and the complexity didn't seem too bad in terms of implementation, but you just have to ensure you check for the other permutations. There may be some cases although where the number of potential chains that you can make is infinite due to the fact that you can re-use dominos. I think in that cases it's valid to consider larger chains "not correct".

@ErikSchierboom you were the one that implemented the exercise, what was your thought process in choosing chain vs canChain?

I'm also always a fan of consistency, and in this case it seems like more tracks have gone with the chain implementation compared to canChain so I'd be in favor of heading that direction.

[ErikSchierboom]

@robkeim The canChain approach was slightly easier to implement, which reduced the difficulty a bit. But now that I see all arguments, I think it would make more sense to convert it to chain. The extra effort I think will not be that bad.

[robkeim]

Ok sounds good!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[robkeim]

I'm going ahead and closing this for the same reason outlined in exercism/csharp#190

[petertseng]

It looks like this track will need to change its README.

The https://github.com/exercism/fsharp/blob/master/exercises/dominoes/README.md says such things like:

Compute a way to order a given set of dominoes

Since this track asks for canChain, this should probably read "Compute whether there exists a way to order a given set of dominoes"

For example given the stones 21, 23 and 13 you should compute something like 12 23 31 or 32 21 13 or 13 32 21

Since this track asks for canChain, this should probably read "For example given the stones 21, 23 and 13 you should declare that there exists a possible chain (for example, 12 23 31 is a possible chain)"

Note upcoming changes to domino text representation in exercism/problem-specifications#972

[ErikSchierboom]

@petertseng At one point there was mention of some tooling to easily synchronize the test descriptions. Do you know if that tooling is available anywhere?