-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why does Source use () instead of Void as the leftover type? #62
Comments
OK, it is clear now why the input type needs to be (), not Void, because NeedInput needs an input value. But the same does not hold for the leftovers. |
Unifying the leftover and input types keeps the function types consistent among Source, Conduit, and Sink. |
Doesn't it prevent using runPipe? What's the advantage of the consistent types? |
Example:
I expect this to type-check, but it does not. |
Oh, I need to use injectLeftovers on both sides. Although that does not make a lot of sense to me, leftovers in a Source. |
My comment about consistent types no longer applies. In the past, the type signature for
in which case the () for leftover in Source was a requirement. So in theory, we could change this to Void now without breaking any of the existing functions. However, I'm not really sure I see a reason to. I like the fact that in the Is there a real downside to the current choice? Certainly it's a bit ridiculous to provide leftovers in a Source, but then again requesting input in a source is just as inane. |
I can think of two things:
|
For point (1): if you're using anything besides ($$), you should really be using GSource instead. And with GSource, the leftover type is required to be free, which is equivalent to specifying it as Void. As for (2), I understand your reasons, but it feels worse to me to have a disparity between the different types. |
Fair enough. I have the feeling that this points to a more fundamental issue with the NeedInput constructor for source-like pipes, though. I think it is a logical error if a source has a NeedInput constructor, and currently this is handled gracefully but perhaps there is a nicer way. Let me think about it! |
I actually consider it one of the downsides to moving to the unified datatype. One thing I played around with a bit was using a GADT for |
Either I'm misunderstanding something, or Source could perfectly well use Void as the leftover type (if there is no input, there can also be no leftovers). Similarly, I suppose the input type could be Void too.
Why is this not so?
The text was updated successfully, but these errors were encountered: