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

[Spiwack, Arnaud]

I find myself in agreement with Richard's comment on Github. Even if we
consider that a new language should implement the proposal (I'm not sure
that I do, but I'm willing to be convinced), I don't think the difference
with the current implementation is worth the change (and, in practice,
maintaining both approaches).

Vitaly, you initially recommended acceptance, maybe you want to argue
further to try and change our minds?

John hasn't replied to Richard's comment on Github yet. Let's see what he
thinks about this, too.

/Arnaud

On Mon, Jun 7, 2021 at 9:59 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> 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
>>
> _______________________________________________
> 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/20210611/cfd6eaef/attachment.html>