Skip to content

Implement exhaustivity checks #855

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

Closed
DarkDimius opened this issue Oct 23, 2015 · 10 comments
Closed

Implement exhaustivity checks #855

DarkDimius opened this issue Oct 23, 2015 · 10 comments

Comments

@DarkDimius
Copy link
Contributor

Better done as a separate phase before pattern matcher.

@DarkDimius
Copy link
Contributor Author

@smarter
Copy link
Member

smarter commented Nov 8, 2015

Note that the Scala equivalent of their vzip example does not compile in Dotty currently because our gadt support is overly restrictive, I hope to be able to fix this at some point.

@liufengyun
Copy link
Contributor

As an update, currently I'm playing with an algorithm outlined as follows:

https://gist.github.com/liufengyun/66bf0c1bc44cdad12e45dd6db689e9b3

The algorithm is basically in the same spirit as what's done in OCaml (Warnings for pattern matching, L. Maranget, 2007), but is more intuitive, easy to adapt for Scala and generate friendly warning messages.

I haven't proved correctness of the algorithm, it's possible to do a mechanised proof. But for now, if it makes some sense to you, I want to focus on implementation and rely on testing to ensure its correctness.

@smarter
Copy link
Member

smarter commented May 13, 2016

@liufengyun : This looks interesting. @adriaanm : the exhaustiveness checker in scalac uses a SAT solver, do you think this is actually fundamentally needed?

@adriaanm
Copy link
Contributor

The solver is not fundamental, but I feel it has made for a nice separation-of-concerns in the pattern matcher analyses. I'm not familiar with Maranget's algorithm, but integrating ML-style pattern matching into Scala's was how the old pattern matcher actually became quite hard to maintain. That doesn't mean all similar approaches are doomed -- just a datapoint.

@liufengyun
Copy link
Contributor

Thanks @adriaanm . To be clear, the algorithm I'm playing with doesn't touch anything related to patmat compilation. If the previous complexity was related to ML-style patmat compilation, that might be a relief.

@adriaanm
Copy link
Contributor

Part of the complexity was because compilation and analysis were intertwined in the old algorithm. The new approach rewrites for optimization, so that you can actually turn off all analyses and do the naive desugaring.

@smarter
Copy link
Member

smarter commented May 13, 2016

What kind of optimizations does the analysis enable?

@adriaanm
Copy link
Contributor

The same logic enables common prefix elimination (e.g., if all outer patterns check the same thing for all cases) but we could do more.

@DarkDimius
Copy link
Contributor Author

Was implemented in #1364

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

No branches or pull requests

4 participants