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
Pattern negation #7628
Comments
Comment author: @xclerc This is a nice idea, immediately translated to ppx_view, see:
|
Comment author: @xavierleroy Mr. Pattern Matching here sounds grumpy about this proposal, but I'll leave it open in the interest of a fair debate. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I still believe that this feature would be important to have: since I have understood that it should exist, I keep finding cases where it would lead to more readable code (often by moving short error cases first in a matching, before long/important clauses). For me the priority is to refactor the existing pattern-matching compiler and make it more robust, not implement new features, but I think that this one has value and would like to keep track of it. I don't understand what is the new unspoken policy on opening/closing feature wishes, but for me this should stay open, because it is a valid feature wish. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Still interested in this feature. (cc @Octachron who was wondering which exciting pattern-matching feature could be considered in the post-refactoring state.) |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I am still potentially interested in implementing the feature. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 7628
Reporter: @gasche
Status: acknowledged (set by @xavierleroy on 2017-09-29T18:17:36Z)
Resolution: open
Priority: low
Severity: feature
Category: language features
Monitored by: @stedolan @yallop @alainfrisch
Bug description
I would like to be able to write the pattern
not p
, wherep
does not contain variables, to match the values that do not matchp
.Pattern negation is useful both in theory and in practice:
In theory, it gives a nice way to describe a decomposition of the value space of a pattern alternation in a way that is independent of pattern ordering/priority. For example, if you see a match with three clauses "| A -> ...", "| B -> ..." and "| _ -> ...", you know that the matched space is the disjoint sum of
A
,B
, andnot (A | B)
.In practice, it gives a convenient way to write patterns in an order that improves readability by treating the exceptional cases first.
Consider this random example:
I think this would be more nicely written
Additional information
In many cases
not []
would be more readable/informative than_ :: _
.The text was updated successfully, but these errors were encountered: