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

Error for unused cases #127

Open
jtrakk opened this issue Jul 4, 2021 · 2 comments
Open

Error for unused cases #127

jtrakk opened this issue Jul 4, 2021 · 2 comments
Milestone

Comments

@jtrakk
Copy link

jtrakk commented Jul 4, 2021

In this example, one of the cases is a typo and always matches. I would like to get a an error for this.

using MLStyle
using MLStyle.AbstractPatterns: literal
MLStyle.is_enum(::T) where {T<:Enum} = true
MLStyle.pattern_uncall(e::T, _, _, _, _) where {T<:Enum} = literal(e)

@enum COLOR Red Green Blue Yellow

julia> @match Green begin
       red => 1
       Green => 2
       Blue => 3
       Yellow => 4
       end
1

OCaml gives a warning.

type colour = Red | Green | Blue | Yellow;;

match Green with 
| red -> 1 
| Green -> 2    (* Warning : this match case is unused. *)
| Blue -> 3     (* Warning : this match case is unused. *)
| Yellow -> 4;; (* Warning : this match case is unused. *)
(* 1 *)
@jtrakk jtrakk mentioned this issue Jul 4, 2021
@thautwarm
Copy link
Owner

thautwarm commented Jul 5, 2021

Our compiler does know this information, however, for a more complex case, the checker can do nothing(I mean, we cannot complete this feature in MLStyle, so I decided not to support an incomplete one):

@data S begin
    S1(Int)
    S2(String)
end
@match xxx begin
    S1(a) =>  ...
    S2(b) => ...
end

In a statically typed language, this will be do-able, but never for dynamic ones: open types and unknown incoming code make the analysis impossible.
In MLStyle, it is hard for the compiler to know the behaviour of pattern deconstruction(we can at most understand the scope of generated code), so checking nested cases is impossible.

@jtrakk
Copy link
Author

jtrakk commented Jul 8, 2021

I found this paper "Lower your guards" which seems interesting. It describes a number of fancy matching rules and says

coverage checking for guards is undecidable in general. However, while we cannot accurately check all uses of guards, we can at least give decent warnings for some common cases.

I wonder what can be done in type-stable Julia, or even JET.jl's analysis framework.

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

No branches or pull requests

2 participants