-
Notifications
You must be signed in to change notification settings - Fork 14
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
Implement universal support for desugaring view patterns #177
Comments
If I understand this issue correctly, the difference comes down to how as-patterns are desugared in the dsAsP :: Name -> DPat -> PatWithExp q DPat
dsAsP name pat = do
pat' <- lift $ removeWilds pat
tell [(name, dPatToDExp pat')]
return pat' But in the instance for dsAsP :: Name -> DPat -> PatWithCases q DPat
dsAsP name pat = do
tell [(pat, DVarE name)]
return (DVarP name) There's a bit of asymmetry here. If you have an as-pattern dsAsP :: Name -> DPat -> PatWithCases q DPat
dsAsP name pat = do
pat' <- lift $ removeWilds pat
tell [(DVarP name, dPatToDExp pat')]
return pat' |
I think that would allow this particular fix to work, however it would still be incorrect in some cases #178 |
Well spotted. But perhaps the issue is that we are trying to desugar patterns in |
There is machinery added in #175 which is able to desugar view-patterns and as-patterns into
(DPat, [(DPat, DExp)])
(the original pattern, and any subsequent patterns which much match their associated expressions). It would be nice to use these in all desugarings, except that the list of subsequentDPat
are potentially fallible, and there are several places which expect these to be infallible.One potential solution to this is to pass down a
failure
clause into wherever this list is eliminated, allowing these patterns to be desugar into two clauses which together match everything.From #175:
The bug here is that now
dsPatOverExp
return a less fallible pattern, having moved most of the matching onas-patterns
into the subsequent let expression. The consequence of this is apparent in the following:This used to desugar to the equivalent of:
But now it desugars to the equivalent of:
Apart from it being incorrect, I do prefer the second one as there isn't any pattern -> expression transmutation happening.
The text was updated successfully, but these errors were encountered: