bowling problem statement does not match code stub

[asarkar]

Requirements

Write code to keep track of the score of a game of bowling. It should support two operations:

roll(pins : int) is called each time the player rolls a ball. The argument is the number of pins knocked down.
score() : int is called only at the very end of the game. It returns the total score for that game.

But in reality:

score :: [Int] -> Either BowlingError Int

[petertseng]

We need to figure out a good way to remove lines from the problem descriptions from problem-specifications, so that we can remove the last four lines of https://github.com/exercism/problem-specifications/blob/main/exercises/bowling/description.md. We already have an easy way to add lines, which is how we are able to append https://github.com/exercism/haskell/blob/main/exercises/practice/bowling/.docs/instructions.append.md, but we have no removal mechanism. Unless the Exercism organisation as a whole adopts some standard, I'd suggest using a .diff or .patch file (just the output of diff) to signify something like that.

For the immediate term I would recommend just removing those lines and committing the .diff file. Tooling that uses the .diff when syncing descriptions can be added later.

[asarkar]

Perhaps a templated problem description with language-specific inserts will work. Something like the following hypothetical template:

common text
<haskell/bowling>

If the snippet doesn’t exist, it has the effect of that tag being absent

[petertseng]

Let's continue to think about long-term solutions, but at the same time allow for short-term ones. To solve this in the short term, the thing to do would to be to remove the offending lines from https://github.com/exercism/haskell/blob/main/exercises/practice/bowling/.docs/instructions.md. I will ask that the .diff file be committed until we find a long-term solution, and if the .diff file ends up not being the long-term solution that we eventually settle on, the .diff files can be converted into whatever the long-term solution actually is. If the need to discuss a long-term solution lasts longer than the lifetime of this issue, I'll create an issue for it at that time.