Skip to content
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

Address some of the fusion issues in #202 #241

Merged
merged 13 commits into from
Jun 21, 2019
Merged

Conversation

nomeata
Copy link
Contributor

@nomeata nomeata commented Nov 16, 2018

in most cases, just updating the docs. More interesting stuff for takeWhileEnd and length, see the corresponding commits. See #202.

it is marked as `NOINLINE` and has no rules that match on it otherwise,
so no fusion can happen.
it would previously replace `takeWhileEnd p` with

    S.reverse . S.takeWhile p . S.reverseStream

But `S.reverse` can only fuse with its argument, and `S.reverseStream`
only fuses with its consumer. So all possible fusion is within this
pipeline, and in the best case we obtain a direct implementation.

There might be some value in this if we had a
`S.reverseStream/S.reverse` rule, so that in multiple chained invocations
of `takeWhileEnd` we could eliminate some intermediat steps. But no such
rule exists at the moment.
There is a comment that

> length needs to be phased after the `compareN/length` rules otherwise
> it may inline before the rules have an opportunity to fire.

but these rules are marked `[~1]`, so we can inline `length` in phase 1
to expose the `stream` in its definition and actually allow it to fuse.
This mirrors commits 1e10823, just for
strict functions.
as it does a case match.
because `dropWhileEnd` is not.
it was matching on `singleton`, but `singleton` gets rewritten to
`s.singleton`. An additional rule makes this robust.
because the rules for `dropWhile` are only enabled before phase 1
nomeata added a commit to nomeata/inspection-testing that referenced this pull request Nov 17, 2018
@nomeata
Copy link
Contributor Author

nomeata commented Mar 20, 2019

Is this mergeable?

@hvr hvr mentioned this pull request Jun 16, 2019
@hvr hvr merged commit 7c86915 into haskell:master Jun 21, 2019
@hvr
Copy link
Member

hvr commented Jun 23, 2019

@nomeata yes, it's mergeable... thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants