[ghc-steering-committee] #351: NoIncomplete, rec: accept

[Alejandro Serrano Mena]

 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 <marlowsd at gmail.com> escribió:

> 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 <bravit111 at gmail.com>
> 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/proposals/0000-no-incomplete.rst
>>
>> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210607/b75ad9f1/attachment.html>