
I am against this proposal, I would say that even in spirit. There are
several reasons for this:
- there’s still a lot of work going on on this same topic (there have been
several papers on the matter in the last 5 years), so I fear that writing
down a spec now would either: (1) deter others from trying, or (2) make
those new rules under a flag like `ExtendedIncompletePatterns` which
everybody will just blindly enable (like `FlexibleInstances` in the past);
- for that reason, I think that incomplete patterns belong to the
warning/error mechanism, something which can point to potential problems or
unexpected behaviours. As part of the development of GHC those errors and
warnings get better;
- the extension is “too local”: it tells you that you’ve missed a case in
*this* `case` statement. Yet, you can get pattern match errors if you use a
function imported somewhere else which doesn’t account for that case.
Regards,
Alejandro
El 29 may 2021 13:31:13, Simon Marlow
I would support this, but only if 1. we specify precisely exactly which pattern matches are accepted, and 2. GHC accepts only those patterns when NoIncomplete is enabled
That is, it would certainly be a subset of -Wincomplete-patterns. No cleverness, no adding extra magic to accept more programs with each release. The point of a spec is to say exactly which programs are accepted, in such a way that different implementations can implement the feature consistently - one implementation is not allowed to accept more programs, otherwise there's no point in having a definition of the feature.
If we don't want to do this (and I suspect it would be annoying to implement), then I think -Werror is the best alternative.
Cheers Simon
On Wed, 26 May 2021 at 13:33, Vitaly Bragilevsky
wrote: Dear Committee,
We have been discussing the NoIncomplete pragma proposal by John Ericson for quite a long time. I think it's ready for acceptance.
The proposal itself: https://github.com/ghc-proposals/ghc-proposals/pull/351 The rendered version: https://github.com/Ericson2314/ghc-proposals/blob/no-sugared-incompleteness/...
The proposal aims to introduce the NoIncomplete pragma that would prohibit programs which have a source of incompleteness (in patterns, in methods) in them. There is also the new -fdefer-incompleteness-errors flag.
I think this feature comes quite handy in education. I'd use it all the time with my students.
Please comment here or in the GitHub thread if you see any problems with this proposal.
Vitaly
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee