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

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 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 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 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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee