-
Notifications
You must be signed in to change notification settings - Fork 80
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
non exhaustive pipes #35
Comments
Here a link to a simple working example based primarily on the existing pipes code. It no longer uses "smart output iterators" as they are too "dumb". I removed the proxies and the pipeline as they weren't need to get this running. |
Here is a more extensive example that removes some of the constraints in the previous one. In the example, the top part in the namespace pipes is essentially code form this library with some modifications. The lower part after The example contains a I'm not sure whether this is a bug or not, but something like
fails with
I added extra code in my
I am still not sure why there is a distinction between pipes and pipelines. The code seems to work fine without it. |
It is probably a good idea. A pipe needs to pass its output to another pipe or pipeline, whereas a pipeline doesn't (it ends with a closing point such as |
It would be really nice if pipes could communicate that they are done. Take for example
take
, where there is some expensive transformation downstream, it would be sweet iftake(n)
would only 'trigger' n calculations. So maybe something like adone()
method could be used to communicate upstream that the pushing can stop. For example the code foronReceive
intransform
looks like this.It does not check whether the
tailPipeline
wants the result. So ifpipes
had a way to check, then we could rewrite this asThe text was updated successfully, but these errors were encountered: