Please feel free to comment and critique anything.
There has been a discussion in issue #555 about the return type of measure(). To keep the discussion focused and have concrete code to talk about I decided to submit this PR now but I'm really open to changes.
This translation uses tuple (possible: bool, moves: int, goalBucket: string, otherBucket: int). For tasks that are possible to solve the function is expected to return a tuple where possible is set to true, for impossible tasks the function should returns a tuple where the member possible is set to false (the unmodified default result will do) and the values of the other members are ignored by the tests.
I looked at the other tracks and how they do it (as far as I understand these languages):
Two tracks use some sort of compound type with a flag member that indicates impossible tasks: The C version and Go version.
They are similar to my translation (in its current state).
Three use some sort of "Optional": The Common Lisp version and Elm version require the function to return NIL/Nothing for impossible tasks.
The Rust version uses an Option that is None for impossible tasks.
One uses some sort of "Variant": The jq version requires two different types for possible and impossible tasks.
I tried to implement this exercise with an Object Variant but that got more complicated, I had to use a ref type and I couldn't figure out how to write simple tests.
But probably you folks know how to do that better, right @ynfle?
I also tried Option.
That is pretty close to this first version with the .isPossible member. I'm not sure which of the two I like more.
From an educational standpoint it would probably be nice to have an exercise with Option.
Please feel free to comment and critique anything.
There has been a discussion in issue #555 about the return type of
measure(). To keep the discussion focused and have concrete code to talk about I decided to submit this PR now but I'm really open to changes.This translation uses tuple
(possible: bool, moves: int, goalBucket: string, otherBucket: int). For tasks that are possible to solve the function is expected to return a tuple wherepossibleis set totrue, for impossible tasks the function should returns a tuple where the memberpossibleis set tofalse(the unmodified defaultresultwill do) and the values of the other members are ignored by the tests.I looked at the other tracks and how they do it (as far as I understand these languages):
Three of them cop out: The Java version, F# version, and Ruby version did omit the tests for the impossible tasks completely.
Two tracks use some sort of compound type with a flag member that indicates impossible tasks: The C version and Go version.
They are similar to my translation (in its current state).
A lot of them use exceptions: The Python version, C# version, Crystal version, JavaScript version, PHP version, PowerShell version, TypeScript version, Vim Script version, and VisualBasic version use exceptions for impossible tasks.
The [Lua version]() wants a failed
assertand the Wren version wants some sort of "abort". I don't know the two languages but I think these are essentially exceptions.Three use some sort of "Optional": The Common Lisp version and Elm version require the function to return
NIL/Nothingfor impossible tasks.The Rust version uses an
Optionthat isNonefor impossible tasks.One uses some sort of "Variant": The jq version requires two different types for possible and impossible tasks.
I tried to implement this exercise with an Object Variant but that got more complicated, I had to use a ref type and I couldn't figure out how to write simple tests.
But probably you folks know how to do that better, right @ynfle?
I also tried
Option.That is pretty close to this first version with the
.isPossiblemember. I'm not sure which of the two I like more.From an educational standpoint it would probably be nice to have an exercise with
Option.