Re: Wincomplete-uni-patterns and bidirectional patterns

On Thu, Jan 18, 2024 at 09:03:25AM +0100, Olaf Klinke wrote:

> > The implementation of a set of patterns (or the underlying type) can
> > change in a manner that changes complete <-> incomplete in either
> > direction. Such changes are non-breaking, provided there was no
> > "contract" (COMPLETE pragma) that the patterns are *intended* to be
> > complete.
> > 
> 
> You are right: It is possible that the types of the bidirectional
> patterns do not change, but the completeness changes. In your example
> given I would argue the contract is broken, because the new patterns
> are for a different type Foo. Instead

A major (often primary) use case of pattern synonyms is with opaque
types that hide their constructors, and expose only pattern synonyms as
"smart constructors".  The internal structure of such types can evolve
without introducing API changes, with the pattern synonyms providing
backwards-compatible behaviour.

My point is that which patterns are expected to be complete is an API
design choice, subject to API stability decisions, and not just a matter
of deductive reasoning.

One might, for example, have a pattern that in the initial API
implementation always matches (it is some sort of property check, that
can't yet fail), and later versions of the API may make it possible for
the pattern to fail (justifying its initial introduction).

-- 
    Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.