You've mentioned wanting to simplify the Choice interface, and this looks like likely to be a good step.
What used to be the third argument is now derived from the first two when needed, using the function choiceGivenInterpreterBasedChoice.
This probably isn't the best choice of function name, and I'm not sure every choice call site's behavior is perfectly preserved by this refactoring. Even if they are mostly preserved, I'd be wary of performance degradation here since the explicit liftWith-style arguments tended to be expressed in ways that were much more direct in implementation. (I haven't even tried to inline choiceGivenInterpreterBasedChoice.)
Hopefully this PR serves as a proof of concept at least. The choiceGivenInterpreterBasedChoice function is pretty simple, and I bet you'll be able to judge if it's a promising approach faster than I can.
You've mentioned wanting to simplify the
Choice
interface, and this looks like likely to be a good step.What used to be the third argument is now derived from the first two when needed, using the function
choiceGivenInterpreterBasedChoice
.This probably isn't the best choice of function name, and I'm not sure every
choice
call site's behavior is perfectly preserved by this refactoring. Even if they are mostly preserved, I'd be wary of performance degradation here since the explicitliftWith
-style arguments tended to be expressed in ways that were much more direct in implementation. (I haven't even tried to inlinechoiceGivenInterpreterBasedChoice
.)Hopefully this PR serves as a proof of concept at least. The
choiceGivenInterpreterBasedChoice
function is pretty simple, and I bet you'll be able to judge if it's a promising approach faster than I can.