forth: Expect a list rather than a string or Text #412
Conversation
There was a problem hiding this comment.
Besides one small change needed in the stub solution, everything seems perfect. 👍
You can take the opportunity to update this exercise to the "new proposed format" if you wish to provide a clean package.yaml, without a dependency on containers.
| @@ -23,5 +23,5 @@ empty = undefined | |||
| evalText :: Text -> ForthState -> Either ForthError ForthState | |||
| evalText = undefined | |||
|
|
|||
| formatStack :: ForthState -> Text | |||
| formatStack = undefined | |||
| toList :: ForthState -> Text | |||
There was a problem hiding this comment.
I think that you forgot to change this line to [Int].
Sure! I will take the opportunity to do so.
Oh dear, maybe I need to speed up the process of doing the "should-compile-but-fail-tests" and we should throw every stub solution into that category. Would prevent this sort of mistake. |
Like in exercism/problem-specifications#394, I request that we question our assumptions. Why have we requested a string? Well, it was like that in exercism/exercism#1188, the first appearance of this exercise. But we can just use a list, right?
This means our package.yaml no longer presents `containers` to students.
|
okay, example is moved - note that I didn't know what to put after Also, maybe I should take a moment to do this for all package.yaml that have extra packages... |
| source-dirs: src | ||
| dependencies: | ||
| - containers | ||
|
|
There was a problem hiding this comment.
Great...you even remembered to remove the comments. :)
|
OK, test passed which is what I was waiting for. If we have no better suggestion than |
|
|
Questioning the assumptions: Why must the output be a string? Reasons I thought of: * It was this way in the original version of the exercise: exercism/exercism#1188 * But, we have no obligation to follow that. * It matches the fact that we have strings as inputs. * But, it is probably more work for the student to create a string. * It can be argued that it's easier to check the vector. Previous discussions: exercism/problem-specifications#394 (comment) exercism/haskell#412 This doesn't get this track all the way to forth 1.0.0, but is a useful step there.
Like in exercism/problem-specifications#394, I request that we
question our assumptions. Why have we requested a string? Well, it was
like that in exercism/exercism#1188, the
first appearance of this exercise. But we can just use a list, right?