Skip to content

Remove some incomplete pattern matches#299

Merged
utdemir merged 2 commits intomasterfrom
ud/complete-pattern-matches
Feb 10, 2021
Merged

Remove some incomplete pattern matches#299
utdemir merged 2 commits intomasterfrom
ud/complete-pattern-matches

Conversation

@utdemir
Copy link
Copy Markdown
Contributor

@utdemir utdemir commented Feb 9, 2021

They only appear when linear-base with ghc HEAD (ab5fd982, slightly
newer than GHC 9.0.1 release). Likely the recent pattern exhaustiveness
checking are relevant, but I don't know why the released version does not throw
these errors.

Anyhow, unfortunately they're only exhaustive because of the implementation
rather than the types, so I added other cases as bottoms.

(Making scanr return NonEmpty would solve one of the problems, but I do
not think it's worth diverging the API from Data.List and also we don't have
Data.List.NonEmpty.Linear)

They only appear when linear-base with ghc HEAD (`ab5fd982`, slightly
newer than GHC 9.0.1 release). Likely the recent pattern exhaustiveness
checking are relevant, but I don't know why the released version throws
these errors.
@utdemir utdemir requested a review from Divesh-Otwani February 9, 2021 23:44
Comment on lines +315 to +316
-- this branch is impossible since we know that 'as' has at least one
-- element inside.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this is not as, this is the result of scanr1. Which, accordingly, is actually not empty.

Copy link
Copy Markdown
Contributor Author

@utdemir utdemir Feb 10, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I was thinking scanr1 returns a non-empty list because as is non-empty; which is unnecessarily indirect. I'll fix the comment.

@aspiwack
Copy link
Copy Markdown
Member

It's probably too late to change this bit of API, indeed. Unless we really really want to. It could make some sense, but we'd have to carefully weigh the option. If I remember correctly, the Generic Scans paper gives scans a type like t a -> (t b, b). where the returned t b has the same shape as the argument, and the singled out b being the sum of the entire structure. Following this example doesn't get us quite the NonEmpty list thing.

I guess that we'll probably keep returning lists.

@utdemir utdemir merged commit 8b84358 into master Feb 10, 2021
@utdemir utdemir deleted the ud/complete-pattern-matches branch February 10, 2021 07:41
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