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

Get rid of an incomplete pattern match #247

Closed
wants to merge 1 commit into from

Conversation

josephcsible
Copy link

No description provided.

@@ -202,7 +202,7 @@ Extract the string that comes before the module declaration...
> . table_text

> lib_content lib_text
> = let (pre,_drop_me : post) = break (== "fakeimport DATA") $ lines lib_text
> = let (pre,post) = break (== "fakeimport DATA") $ lines lib_text
Copy link
Member

Choose a reason for hiding this comment

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

Should we make such a change? I think it is hurting code comprehensibility more than helping it.
The current formulation makes clear that the _drop_me : post match MUST succeed, even if GHC does not see it.
The new formulation clouds this insight.
So, I am against such a change.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes it would be better to add an explicit pattern match with an error .... It would be even better to try to use NonEmpty.

Copy link
Member

Choose a reason for hiding this comment

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

NonEmpty is available from base-compat for old GHC versions back to 7.0 (base-4.3), so that would not be a problem for keeping all currently supported GHC versions.

@sgraf812
Copy link
Collaborator

Fixed the incomplete match warnings in #281.

@sgraf812 sgraf812 closed this Jul 22, 2024
@josephcsible
Copy link
Author

I'd argue that #281 didn't fix anything, but merely hid the warnings.

@andreasabel
Copy link
Member

Well, the problem with these warnings is that you cannot switch them on a case-by-case basis.
The workflow would be:

  1. The partiality warning is raised.
  2. The case is investigated.
  3. a. If the partiality can definitively not occur at runtime, the warning is switched off for this case.
    b. If the situation is unclear, the case should be fixed to catch a possible partiality.

For this issue, we are in case 3a, but unfortunately GHC only allows us to switch off the warning globally.

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.

4 participants